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I. INTRODUCTION 


A. BACKGROUND 

Manpower end-strengths, both military and civilian, for 
the Department of the Navy, are authorized annually by 
Congress and reflected in the Secretary of Defense's 
(SECDEF) Six Year Defense Program (SYDP). Identification of 
future manpower requirements is an integral part of the 
Planning, Programming, and Budgeting System (PPBS) process. 
Manpower requirements are determined by force structure, 
weapons systems configurations, warfare tasking and support 
thereof. 

In a peacetime environment of increasing budget cuts 
resulting in reduced manning levels, it is vital that 
limited manpower assets be actively managed to ensure 
mission accomplishment and battle readiness. Manpower 
analysis is the process by which an activity's personnel 
assets are matched to or balanced against authorized billets 
to determine strengths and weaknesses in manning structure. 

The activity commander must be aware, at all times, of 
how his/her manning structure (personnel assigned) balances 
against the activity’s billet structure (job organization). 
Manpower assets must be monitored not only for current 


status but also for future required manning levels based on 


mission requirements and operational commitments. 
Assignment of personnel to an activity normally requires 
four to seven months lead-time. Therefore, manning 
shortfalls cannot usually be relieved quickly and must be 
planned for well in advance to ensure mission readiness. 

A case/example helps illustrate this point. An 
overseas, lsolated Naval activity had a billet authorization 
(BA) for a single Utilitlesman (UT2) with a critical 6104 
Naval Enlisted Classification Code (NEC), alr-conditioning 
(AC) repair. It is vltal to mission accomplishment that at 
least two of the three air-conditioners for climate control 
in the computer building be operational at all times. The 
nearest available civilian contract AC repair support was 
Six hours automobile drive from the activity. No other 
military support was available at a shorter distance. 

Two weeks before the assigned UT2's projected rotation 
date (PRD), the command suddenly realized they had no relief 
on board or anyone ordered in as relief. The incumbent UT2 
could not be held at the activity as his presence was 
required for onboard relief at his next duty station. 
Through intervention of their Immediate Superior in Command 
(ISIC), the manning control staff of Commander in Chief 
Atlantic Fleet, and the Enlisted Personnel Management 
Accounting Center (EPMAC), a relief was detailed to and 
received by the activity two days prior to the incumbent's 


departure. 


Had this activity performed manpower analysis on, say, a 
monthly basis, they would have recognized well in advance of 
the UT2’s PRD that an onboard relief was critical to mission 
accomplishment and could have solved the problem long before 
intervention by senior commands was required. 

On the other hand; if performed properly, manpower 
analysis can result in early identification and resolution 
of potential manning problems as the following case 
illustrates. This case is for a shore activity with a 
requirement for approximately a dozen Data Processors (DPs). 
These DPs worked with a mainframe computer which was used 24 
hours a day for real-time data analysis. The computer room 
was required to be manned 24 hours a day, on a rotating 
basis, by qualified watch-standers. At least four months on 
the job training was required to qualify an individual to go 
on the watch bill. 

By conducting manpower analysis, the Division Officer 
was able to verify the readiness of his division. The 
majority of his DPs were female, limited duty personnel 
(because of pregnancy) received from ships. The remainder 
of his division were male and female permanently assigned 
petty officers and seamen. 

About the time the limited duty personnel were finished 
qualifying for watch, they were placed on restricted work 
hours by medical (precluding watch standing duties) followed 


Shortly thereafter by maternity leave. Generally these 


individuals did not return to the shore activity at the end 
of their convalescent leave, but returned to full duty 
onboard their ships, thereby limiting the number of 
quallfled watch standers to the few permanent party DBs. 
Because proactive manpower analysis was performed, the 
shore activity was able to show precisely the impact on 
current and future mission readiness of this limited duty 
assignment policy. Through close work with the DP detailing 
Staff at Naval Military Personnel Command (NMPC), this 
activity was able to have the number of limited duty 
assignments to them drastically reduced and the required 


nunber of regular PCS DPs restored.! 


B. PROBLEM STATEMENT 

Upper echelon Navy staffs have trained personnel 
assigned specifically as manpower analysts. At the lower 
echelon staff and activity levels, however, the 
responsibility for manpower analysis falls to the Executive 
Officer, Department Heads, and Division Officers who, 
generally, have had no formal training in this process. 

Few Naval officers are formally or even informally 
trained in the manpower analysis process, yet this is a 


vital part of effective management of scarce personnel 


! By policy, medical limited duty personnel are not to be 
counted against normal BA. However, this activity found that the 
quantity of onboard permanently assigned DPs was substantially 
below NMP. 


resources. Normally, when an officer reports for duty to an 
activity, he/she receives turnover/passdown as to the 
mission of the command and division/department. This 
passdown generally includes a list of personnel assigned to 
that work area and a description of the duties each 
performs.  Rarely is an officer given a copy of the 
authorized billet structure for his/her division/department 
or shown how the personnel assigned relate to that billet 
structure. 

Generally, formal manpower analysis is performed at the 
higher echelon staff levels, usually by officers assigned 
specifically as manpower analysts. If manpower analysis is 
performed at the activity level, it is usually by personnel 
who happen to use manpower analysis techniques because of 
previous work experience in that area. An activity's 
manpower analyst should have an understanding of the 
complexity of the command's operational mission and 
administrative support requirements; how the billet 
structure is determined; what quantity of billets are 
required for full mission readiness; why there is a 
difference between Billet Authorizations and Billet 
Requirements; why a specific rating mix of personnel is 
assigned; and how the number of personnel assigned is 
determined. Knowledge of each of these areas is required in 
order to perform effective manpower analysis at any activity 


level. 


The primary problem with the current system of manpower 
analysis employed at the activity level in the Navy is that 
Manpower Analysis training is not part of the formal officer 
training program. Most junior officers (LCDR and below) do 
not know what a Manpower Authorization (MPA) is or how to 
read it. Additionally, few officers ever see an Enlisted 
Distribution Verification Report (EDVR) or Officer 
Distribution Control Report (ODCR) or Manpower Document 
until they reach the Department Head or Executive Officer 
level. Generally, only those officers assigned duties as 
manpower analysts, such as Aviation Maintenance Officers in 
aviation squadrons, are ever required to use manpower 
analysis documents in the management of their workcenter, 
division, or department. Usually officers are completely 
unaware of their authorized billet structure and rely 
strictly on the roster of personnel assigned to them in 
order to identify workcenter structure. This lack of 
knowledge of manpower analysis documents and techniques 
results in poor planning for future manning needs. Formal 
manpower analysis is often not even done at a divisional or 


departmental level. 


C. OBJECTIVES 
The general objective of this thesis is to define the 
activity level manpower analysis process and to present a 


design for an automated database for performing this 


process. This objective will be accomplished by presenting 
a functional description of manpower analysis, fully 
defining data inputs for the analysis process, and providing 
examples of possible outputs of the system used by various 
levels of a Naval activity. It is envlsioned that 
automatlng the manpower analysis process at the activity 
level w111 readily accomplish education on the importance 


and the mechanisms of the process. 


D. RESEARCH QUESTIONS 
The area of research is limited to respond to four 
questions: 
1. From a staff, organizational, and departmental 
or divislonal level, what functional requirements 
must be addressed to support effective activity 
level management of manpower resources? 
2. What data elements are requlred to evaluate an 
activity'/s manpower profile? 
3. What manpower reports are required at each 
management level of an activity to support manpower 
planning and management? 
4. What additional personnel administration areas 
can be addressed with this system and what 


modifications will be required? 


E. SCOPE AND LIMITATIONS 

This thesis will provide background information on the 
Department of Defense/Navy (DOD/DON) manpower development 
process and a description of the documents used at the 
activity level for manpower analysis. Functional and Data 
requirements for activity level manpower analysis will be 
identified, and a logical database design presented. 
Examples of outputs and reports will also be included. 

The scope of this thesis is limited to system analysis 
and design. It does not include implementation of the 


proposed design or building of a prototype. 


F. METHODOLOGY 


Object oriented database analysis and design methodology 


Will be used to define functional and data requirements and 


to present a logical database design. This methodology will 


be described in Chapter III, User Requirements. 


Functional and data requirements for this system will be 


based on the author's professional experience as a U.S. Navy 


Manpower Analyst for six and one-half years at the Echelon 
three, four, and five levels: Commander Oceanographic 
System Atlantic (primary billet - 1983-85); Commander 
Helicopter Tactical Wing One (1985-88); and Naval Air 


Station, Agana, Guam (1980-81), respectively. 


G. ORGANIZATION OF THESIS 

This thesis is organized as follows: 

Chapter II, entitled "Manpower Management in the Navy", 
reviews the Department of Defense/Navy (DOD/DON) level 
processes for determining activity manpower requirements. 
Views of manpower from the three upper levels of management 
at an activity will be presented and the documents required 
for activity level manpower analysis will be reviewed. 
Reports generated by the manpower analysis process will be 
presented within the context of management views of 
manpower. 

Chapter III, entitled "User Requirements", reviews the 
methodology used to define data and functional requirements, 
develops the objects to be stored in the database, and 
determines the processes that create, modify and display 
these objects. Using data from several sources, a database 
is defined which contains information on personnel assigned 
to an activity and the activity’s billet structure. The 
database system, once designed, will process the information 
from the database to produce a series of predefined reports 
or respond to ad hoc queries on the database. 

Chapter IV, "Design", presents the logical database 
design using Object Oriented methodology and the Relational 
Database Model. Using this methodology, objects identified 


in the previous chapter are transformed into a relational 


diagram. Data flows and report outputs of the system are 
also specified in, Appendices C and D, respectively. 

Chapter V, entitled "Summary and Conclusions", provides 
a brief review of the previous four chapters and presents 
suggestlons for alternative functionality of the system. 

Appendices A through C provide Object Diagrams, Object 
Specifications and Object Oriented Data Flow Diagrams, 
respectively, developed during the Requirements Analysis 
phase. Appendix D provides Sample Forms/Data Input/Display 
Screens and Reports designed for data input and modification 
and data output, respectively. Appendices E and F were 
developed during the design phase of this thesis and provide 
a graphic, Appendix F, and literal description of 
relationships between the Objects presented in Appendix A. 
Appendix G defines system requirements for Update, Display, 
and Control Mechanisms. Appendix H illustrates the system 
Menu Hierarchy and provides sample menus for the system. 
Appendix I provides Pseudo Code for the Menu Hierarchy as 


well as for the reports generation procedures. 
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II. MANPOWER ANALYSIS 


Chapter I provided a brief background on the manpower 
analysis process and the importance of that process. This 
chapter reviews the Department of Defense/Navy (DOD/DON) 
level processes for determining activity manpower 
requirements. Views of manpower from the three upper levels 
of management at an activity are presented, and the 
documents required for activity level manpower analysis are 
reviewed. Reports generated by the manpower analysis 
process are presented within the context of management views 


of manpower. 


A. DEPARTMENT OF DEFENSE/NAVY (DOD/DON) MANPOWER 
PROGRAMMING 

Manpower requirements for the DOD/DON are determined, in 
part, by the authorized configuration of weapons systems, 
force structure, warfare tasking, and support thereof. A 
Naval activity's billet structure is, therefore, directly 
linked to the Department of Defense's (DOD) Planning, 
Programming, and Budgeting System (PPBS). Initiated 
annually, the PPBS operates on an eighteen month cycle. 
Events in this cycle lead directly to the development and 


authorization of Navy manpower. 


Je 


1. DOD Planning, Programming, and Budgeting System 

(PPBS) 
The President, National Security Council, Joint 

Chiefs of Staff (JCS), and DOD evaluate the threat to 
national security based on intelligence collected. The JCS 
then develop a strategy to meet these threats to national 
security and promulgate it in the Joint Strategic Planning 
Document (JSPD) to the Secretary of Defense (SECDEF). The 
SECDEF then issues guidance to the Military Departments in 
the areas of Fiscal Policy, Material Support Planning, and 
Preparation of the Program Objective Memorandum (POM). The 
military departments submit POM to the SECDEF in response to 
this guidance. The POM submissions contain recommendations 
as to the forces and resources required to support national 
defense objectives as well as the rationale for these 
recommendations and risk assessments. Once force 
requirements have been determined, manpower requirements 
necessary to support the forces are established. 
[Ref. 1:Chap. 3]. 

2. DOD POM 

POM submissions are fiscally constrained and 

developed by fiscal year. Planned forces are programmed for 
eight fiscal years, and the manpower to support the forces 
is programmed for six fiscal years. "Upon receipt of the 


POM submissions from each Military Department, the SECDEF 
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requests the JCS to prepare the Joint Program Assessment 
Memorandum (JPAM)". (Ref. 1:Chap. 3]. After analyzing the 
POM submissions and the JPAM, the SECDEF issues Program 
Decision Memorandum (PDMs) which include intended 
adjustments to the POM submissions. The Military 
Departments submit budget estimates based on Program 
Decision Memorandum to the SECDEF. After evaluating of 
these budget estimates, by SECDEF and Office of Management 
and Budget (OMB). SECDEF develops "... Decision Package 
Sets and submits the DOD budget as part of the President’s 
budget to Congress".* [Ref. 1:Chap. 3]. Figure 2-1 
illustrates this PPBS process. Figure 2-2 illustrates the 


entire Manpower Requirements Determination Process. 


B. DON MANPOWER REQUIREMENTS DETERMINATION 
1. Operating Forces 

In the Department of the Navy (DON), determining the 
manpower requirements for operating forces, i.e. ships, 
submarines, and aviation squadrons, is a complex process 
based on established engineering standards and other 
methodologies. Beginning with an operating unit's Required 
Operational Capability (ROC) or mission statement, and the 
Projected Operational Environment (POE) or specific 


operating scenario, then determining operating and 


“Budget decisions are contained in Program Budget Decision 
(PBDs) and Defense Management Review Decisions (DMRDs). 


T3 


Joint Chiefs of Staff 


(JCS) 
(Step ini pe: 1) 


Joint Program Joint Strategic 
Assessment Memorandum Planning Document 
(JPAM) (JSPD) 
Decision Package Sets (Step 7) Secretary of Defense 
and DOD Budgetto — -44— —————— (SECDEF) 


Presidents Budget 
(Step 2) 


Guidance on Fiscal 


Program Objective Policy, Material Support 
Memorandum (POM) (Step 3) Planning and POM 








Budget Estimates Program Decisions 


(Step 6) / 


Military Departments 
(DON,DOAF, DOA) 


(Step 3) 


Figure 2-1:  PPBS Process 
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malntenance requirements for equipment installed at that 
unit to support the ROC/POE, the manpower analyst can apply 
a set of algorithms and engineering standards to determine 
the billet/manpower quality and quantity mix required for 
the unit to be fully mission capable. The wartime or full 
mlssion requirement blllet structure for each unit in the 
operating force is then published in the unit's Manpower 
Document. 

Each Ship Manpower Document (SMD) and Squadron 
Manpower Document (SQMD) identifies the "minimum wartime 
qualitative and quantitative manpower requirements to 
support accomplishment of all assigned missions and Required 
Operational Capabilities in the Projected Operational 
Environment ROC/POE". (Ref. 1:Chap. 2]. These documents 
delineate, by departmental and divisional breakdown, the 
required officer and enlisted billet structure for an 
activity. This structure is defined in terms of officer 
warfare designations and grade; enlisted ratings, 
subspecialties or NECs, and paygrades; and the quantity 
required of each. 

2. Shore Activities 

The mission of Navy shore activities is to provide 
support to the operating forces. This support includes, but 
is not limited to, mission areas such as supply, fire 


fighting, intelligence, aircraft/ship rework, and staff 
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administrative activities. These support functions are not 
directly related to the operations of war-fighting hardware; 
therefore, the manpower effort required to provide these 
services cannot be measured by hardware engineering 
standards. 

The current method being used by DON to determine 
shore facility billet structure is the Efficiency Review 
(ER) process. Completion of ERs on all Naval shore 
activities is scheduled for FY 1994. From this process the 
Most Efficient Organization (MEO) which "defines the minimum 
quality and quantity of manpower required to produce the 
output(s) established in the activities Performance Work 
Statement (PWS)" will be derived. (Ref. 1:Chap. 3]. "The 
Objective is to develop a manpower requirements baseline to 
use as a basis for programming all shore manpower 
requirements". (Ref. 1:Chap. 2]. The end result of this 
entire process will be a Shore Manpower Document (SHMD), 
similar in structure to the SMD and SQMD, for each U.S. Navy 
shore activity. 

3. Manpower Authorization (MPA) (OPNAV 1000/2) 

The next step in the manpower process is to 
determine peacetime mission requirements for all Naval 
activities, operating forces and shore activities. From 
these requirements, the peacetime force structure (ships, 


submarines, and aircraft, etc.) and shore facilities 
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structure are determined within budgetary constraints set by 
Congress. The Manpower Authorization (MPA) (OPNAV 1000/2) 
outlines Chief of Naval Operations (CNO) approved and funded 
billets for each Naval activity based on budgetary 
constraints, warfare priorities, and manning policies. 
Currently the DON's goal is to have billet authorization 
(BA) levels at 91.5 percent of requirements for operating 
forces (deployable, military personnel only) and 90 percent 
or less of requirements for shore facilities (combined 
military, civilian, and civilian contract personnel). 
(Refs. 2 and 3]. 
4. Personnel Levels 

The actual number of personnel assigned for duty to 
a Naval activity at any given time is determined by a 
complex set of factors, the explanation of which is beyond 
the scope of this thesis. It is sufficient to understand 
that the quality and quantity mix of personnel assigned to 
an activity ranges from 70 to 88 percent of BA, with each 
activity receiving its "fair share" of Navy personnel assets 
as determined by the Navy Manning Plan (NMP) for Enlisted 
personnel and the Officer Navy Manning Plan (ONMP). 
[Refs. 2 and 3]. Because there is a difference between BA 
levels and actual personnel on board, it is vital that 
managers recognize this fact and manage these limited assets 


to ensure mission accomplishment and combat readiness. 
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C. PRESENT SYSTEM - ACTIVITY LEVEL MANPOWER ANALYSIS 
1. Personnel and Billet Data Sources 

The location of Naval personnel, based on official 
Permanent Change of Station (PCS) orders is maintained in 
database systems at the Consolidated Data Center (CDC) in 
Cleveland, Ohio. These systems are the Naval Enlisted 
System (NES) and the Officer Personnel Information System 
(OPINS), commonly referred to as the Enlisted Master File 
and the Officer Master File. However, direct access to 
these databases is restricted to the upper echelons of the 
DON. 

Lower echelon activities such as ships, aviation 
squadrons and Naval bases do not have direct access to these 
database systems. Therefore, in order to fully analyze 
their manpower, data from several sources, internal and 
external to the command, are required. Internal documents 
include the personnel service records and personnel rosters. 
Externally generated documents used in activity level 
manpower analysis include the following: 

a. Manpower Authorization (MPA) (OPNAV 1000/2) 

The Manpower Authorization (MPA), produced by the 
Navy Manpower Data Accounting System (NMDAS), is used to 
fully identify the peacetime and mobilization billet 


structure of an activity. Two MPAs are published for each 
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command, one for officer billets and one for enlisted 
billets. Both are divided by department and division, and 
the billets assigned to each are delineated. 

Billets are identified by Billet Sequence Code 
(BSC) and Billet Title. Each billet is then assigned 
specific enlisted rating and Primary and Secondary Naval 
Enlisted Classification codes (PNEC/SNEC) requirements or 
officer warfare designator, grade, and subspecialty codes, 
if applicable. The authorized peacetime quantity for each 
billet is specified for the current Fiscal Year (FY) and 
subsequent five FYs. 

MPAs for an activity must be reviewed when the 
activity receives a new edition in order to identify or 
verify changes, if any, which have occurred to the 
authorized peacetime or wartime billet structure. Changes 
to an activity's billet structure are also identified 
through correspondence from the appropriate resource 
sponsor. For example, changes would include notification 
that an NEC is to be to be applied to specific ratings or 
notification granting authority to establish a new 
department within an activity and providing its associated 
billet structure. 

b. Enlisted Distribution Verification Report (EDVR) 

The Enlisted Distribution Verification Report 


(EDVR), produced by NES, is received monthly by each Naval 
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activity with enlisted personnel assigned. This document 
lists assigned enlisted personnel alphabetically by last 
name and alphabetically by rate. Information provided on 
each person includes his actual rating and assigned rating 
(rating detailed against), PNEC/SNEC held and distributed 
against, Projected Rotation Date (PRD), End of Active 
Obligated Service Date (EAOS), Active Duty Service Date 
(ADSD), and Social Security Number (SSN). Prospective 
personnel gains and losses are also identified by name and 
rate and estimated date of arrival or departure, 
respectively. The activity’s billet authorization level and 
current month and nine month projected onboard manning 
levels are also provided as well as the NMP allotment for 
each rating. 

c. Officer Distribution Control Report (ODCR) 

The Officer Distribution Control Report (ODCR), 
produced by OPINS, also published monthly, lists officers 
assigned to a command by BSC and Billet Title. Grade, 
designator, subspecialty, date of rank, PRD, sex, and SSN 
are also provided. 

Information on officer and enlisted personnel is 
also gleaned from Permanent Change of Station (PCS) orders 


and an individual’s Personnel Record. 
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d. Detalling of Personnel 
Although officers are officially detailed to a 
specific billet within their activity, they may actually be 
assigned to a different billet by their Executive or 
Commanding Officer once they report for duty.  Enlisted 
personnel are generally not detailed to a specific billet, 
but to an opening for a specific rating and paygrade or NEC 
requirement. There are exceptions to this system for 
enlisted personnel such as directed manning for Command 
Master Chief, Command Career Counselor billets and other 
high interest or controlled billets. When an enlisted 
member reports to an activity he/she is assigned to a 
department or division. The officer in charge of his/her 
work unit then assigns specific duties to be performed by 
the individual. 
2. Activity Management Levels 

There are three levels of management in an activity 
that are concerned with billet/personnel management: 

a. Executive Level 

This level consists of the Commanding Officer 

(CO), Executive Officer (XO), and selected Executive 
Assistants such as the Command Career Counselor (CCC) and 


Command Master Chief (CMC). 


Ze 


b. Department Heads 
Department Heads are offlcers who are assigned 

responsibility for a major mission component of an activity 
such as Operations, Weapons, or Administration. Department 
Heads are assigned responsibility for managing several 
subordinate officers and numerous enlisted personnel who are 
grouped into functional subareas, called divisions, within a 
department. 

c. Division Officers 

Officers at this level of management are assigned 
responsibility for a division within a department. A 
division includes numerous enlisted personnel of varying 
rates. 
3. Management Views of Manpower 

The Executive Level, specifically the CO and XO, 
view enlisted manpower differently from the other two levels 
of management discussed above. The CO and XO generally view 
enlisted manpower in terms of the quantity of personnel 
onboard in each department or division; percentages of 
personnel onboard versus Billets Authorized (BA); a specific 
comparison of the number of billets and personnel assigned 
per department and division; and projected shortfalls and 
end strength. 

Officer manpower, on the other hand, is viewed from 


this level in terms of an individual assigned against a 
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specific blllet, as well as overall current and projected 
officer manning levels. The Executive Officer of a command 
is responsible for the billet assignment of officers. The 
other members of the Executive Level, the CCC and CMC, deal 
primarily with career development, and morale and welfare of 
enlisted personnel, respectively. 

Department Heads and Division Officers view enlisted 
manpower in terms of BA versus personnel assigned ratios as 
well as specific enlisted billet assignments. Department 
Heads and Division Officers must actively project future 
manning levels against specific billets to ensure combat 
readiness and mission accomplishment. 

4. Manpower Analysis Process 

As mentioned previously, manpower analysis is the 
process by which an activity’s personnel assets are matched 
to or balanced against its authorized billets. Often the 
manpower analysis and reports generation process at an 
activity is a manual process performed by an officer 
assigned as the Command Manpower Analyst or by an individual 
Department Head or Division Officer for their respective 
department, division, or work centers. These reports can 
take anywhere from a few minutes to several hours to produce 
manually, depending on the data required and the accuracy, 


currency, and availability of the data. 
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Because of the time lag between NES and OPINS 
database updates, publishing dates, and receipt of the EDVR 
and ODCR by an activity, there are frequently discrepancies 
between data in these documents data in and the individual's 
personnel record. The same is also true for NMDAS and the 
MPA. Information gleaned from the MPA, EDVR, ODCR, PCS 
orders, Personnel Records, billet assignments, and 
personnel/billet correspondence from higher authority is 
used to manage billets and manpower within an activity. 
Figure 2-3 illustrates the flows of data through the 
manpower analysis system. 

a. System Data Flows 

Figure 2-3 illustrates a general view of activity 
level manpower analysis. Sources and sinks as well as 
senders and receivers of data within the system are 
represented by boxes. The term 'Higher Authority' refers to 
an activity at an echelon higher than the activity 
performing manpower analysis. These Higher Authorities are 
responsible for making decisions on billet structure and 
assignment of personnel for subordinate activities. 

Higher Authority activities, in the context of 
this thesis, are as follows: 

- Chief of Naval Operations (OP-12), 


responsible office for MPA changes as 
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Figure 2-3: Manpower Analysis Process Data Flow Diagram 
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directed by resource sponsors and manpower 
claimants. 

- Resource Sponsors, offices within OPNAV 
responsible for ensuring resources are 
available in the various warfare communities 
for mission accomplishment. 

-  EPMAC, performs placement for all active 
and Training and Administration of Reserves 
(TAR) enlisted duty personnel; detailing of 
non-designated airmen, seamen, and firemen; 
NEC management; production and distribution 
of EDVR using NES. 

- Naval Military Personnel Command (NMPC), 
responsible for detailing and placement of 
officers, and detailing of all other enlisted 


personnel. 


Data flowing from Higher Authority will include 


billet information and personnel assignment information. 


Data flowing from the Commanding 


Officer/Executive Officer (CO/XO) source to the system will 


normally include only officer billet assignments. 


Information flowing to the CO/XO sink will be the various 


manpower analysis reports produced by the system and 


required by this level of management. These reports will be 


discussed in Section 5 of this chapter. 
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Division Officers and Department Heads will 
provide data to the system concerning enlisted billet 
assignments. As a data sink, this level of management will 
use reports generated by the system. 

Data from the Personnel Record will be used by 
the system to update the database, but no information or 
data will be sent from the system to the personnel record. 

b. Major System Components Data Flows 

Figure 2-4 illustrates the flow of data into and 
out of the two major components of a manpower analysis 
system. These major components are the processes for 
managing billet and personnel data and for creating reports. 

The data management process encompasses 
mechanisms for adding new data, modifying existing data, and 
deleting data which is no longer required. The primary 
purpose of any database is to maintain data for use by 
decision makers. The manpower analysis process ultimately 
produces reports for the users which present various 
consolidated views of an activity's manpower. Additionally, 
the database should be capable of providing simple lists of 
groups of data as well as responses to ad hoc queries. 

5. Reports 
Reports generated by the manpower analysis process 
are reflections of the management views of manpower. 


Reports on officer manpower would include a break-down of 
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Figure 2-4:  Subprocesses Data Flow Diagram 
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personnel by paygrade and/or rank, billet summary by 
department/division, and a designator summary. Enlisted 
reports would include essentlally the same break-down 
proflles. Both officer and enllsted reports provide 
strictly numeric views of the information in the database as 
well as views of specific blllet/personnel assignments. 
Appendix D provides samples of reports illustrating views of 
the data normally required by activity level management. 
(These reports will be discussed in detail in Chapter III). 
Not all levels of management need to see the same levels of 
detail in a report; therefore, the manpower data must be 


combined, analyzed, and presented in different formats. 


D. SUMMARY 

This chapter provided background information on the 
DOD/DON level manpower requirements determination processes. 
At the DON level, several documents are generated which, if 
used by an activity, provide all of the data necessary for 
effective manpower analysis. The manpower analysis process 
Was summarized and an overview of reports generated by the 
process was presented. 

Chapter III reviews the methodology used to define data 
and functional requirements, develops the objects to be stored 
in the database, and determine the processes that create, 


modify and display these objects. 
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III. SYSTEM REQUIREMENTS 


This chapter defines the data and functional 
requirements for an automated manpower analysis system. 
Using data from several sources, a database is created which 
contains information on personnel assigned to an activity 
and the activity's billet structure. The database system 
will then process the information from the database to 
produce a series of predefined reports or to respond to ad 


hoc queries on the database. 


A. METHODOLOGY 

Object oriented methodology is used to define data and 
functional requirements for the database system. Using this 
methodology, the entities in the user'/s work environment are 
represented as objects to be stored in the database. An 
entity is any item in the user's work environment about 
which information is required to be stored. For example, an 
Officer would be an entity in a Naval activity’s personnel 
management environment. The characteristics of each object 
are defined in terms of the data elements to be stored. 

Functional requirements for the database system are 
defined through the use of Data Flow Diagrams (DFDs).  DFDs 


present graphically how each object in the user's work 
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environment is created, modified, deleted, and displayed. 
DFDs also illustrate who is authorized to do what to each 
object and, within the user's work environment, to whom 
information from the system is given. 
1. DATA REQUIREMENTS DEFINITION 
Using object oriented methodology, the systems 
analyst must first identify those ‘objects’ in the user's 
environment that must be maintained and define their 
structure. An object is defined as a "... named collection 
of properties that sufficiently describes an entity in the 
user's work environment." A property is a "... 
characteristic of an entity that is important to one or more 
users of the database application ...", such as a person's 
name or rank.’ "An entity is something the user perceives 
to be an independent unit...", such as a department or an 
officer. (Ref. 4:Chap 4]. 
a. Object Definitions 

To define the objects in the user's environment 
for the AMA/PMS, both system outputs and entities in the 
user's work environment were examined to fully identify the 
characteristics or properties to be maintained by euer 
system. These objects represent a consolidated view of the 


entities and their characteristics in the user's 


ÎA property of an object may also be another object. In this 
case it is called an object property. 
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environment, a Naval activity. All Naval activities are 
divided into departments which are then divided into 
divisions. Some divisions are then further divided into 
workcenters (for the purpose of this thesis, an activity 
will be subdivided only to the division level). Personnel 
are assigned to work within specific departments and 
divisions at an activity. The manpower of a Naval activity 
is viewed in terms of billet structure and personnel 
onboard. 

From the object oriented view of activity 
manpower, six entities are identified in the user's work 
environment of Manpower/Personnel Management about which 
data must be maintained. For the AMA/PMS these entities are 
defined as the objects: DEPARTMENT, DIVISION, OBILLET 
(officer billet), EBILLET (enlisted billet), OFFICER, and 
ENLISTED. Appendix A graphically presents the properties of 
each object. 

b. Object Specifications 

Once the objects have been defined, object 
specifications are developed. 

"Object specifications consist of two parts: object 
definitions and domain definitions. An object 
definition lists all the properties of an object and 
indicates the domain from which values for each property 
may be drawn. Domain definitions specify formats, 


lengths and special restrictions on the values of each 
domain". (Ref. 4:Chap 4]. 
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Object Definitions and Domain Definitions are presented in 
Appendix B. 
c. Object Descriptions 

(1) Department and Division Objects. The 
billets^ within an activity are divided into Departments and 
then subdivided into divisions. For example, the Aviation 
Maintenance Department would include divisions called 
Scheduling, Avionics and Electronics. The DEPARTMENT object 
is identified by Dname. This object contains the object 
properties of DIVISION, OBILLET, EBILLET, OFFICER, and 
ENLISTED, all of which may be multivalued. 

The DIVISION object is identified by 
DivName. This object also contains the object properties of 
OBILLET, EBILLET, OFFICER, and ENLISTED, as well as the non- 
object property Dname. Again, each of these object 
properties may be multivalued. 

(2p Billet Objects. Billets are categorized 
as requiring either an officer or an enlisted person to be 
assigned. The objects defined to represent these entities 
are OBILLET and EBILLET. Billet data is obtained from the 
Manpower Authorization (MPA) OPNAV 1000/2 or via official 
correspondence from a Resource Sponsor which identifies 


changes to an activity’s billet structure, hereafter 


‘The billet structure of an activity defines the job 
organization. Therefore, a billet is a specific element of the 
work breakdown structure of the activity. 
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referred to as a Notification Letter. Billet data is 
entered into the system to create, modify, or delete a 
unique instance of OBILLET or EBILLET objects. These 
instances of OBILLET and EBILLET objects are then grouped to 
create instances of DEPARTMENT and DIVISION objects. 

The OBILLET and EBILLET objects contain 
several identical properties. Both objects are identified 
by a Billet Sequence Code (BSC) which is unique to each 
instance of that object. Each contains properties called 
Billet Title; Billet Authorization (BA), the number of 
billets authorized for that BSC; Department Name (DName) ; 
and Division Name (DivName). All billets are assigned to a 
department, but not all billets are assigned to a specific 
division. Several billets may be assigned to an area within 
the department commonly referred to as Departmental 
Administration. 

The OBILLET object contains properties for 
Grade and Designator (indicating the rank and warfare 
designator, respectively), ideally required for that billet. 
Additionally, one or more instances of OFFICER object may be 
associated with a specific instance of the OBILLET object.? 

Properties within the EBILLET object are 


Rating, an alphanumeric acronym for an enlisted technical 


°More than one officer may be temporarily assigned to a single 
instance of OBILLET during periods of personnel turnover and 
reassignment. 


35 


rate and paygrade; paygrade; Primary or Secondary Naval 
Enlisted Classification (PNEC/SNEC) code, a numeric code 
specifying a technical subspecialty within a specific 
rating; BA; Dname; and DivName. One or more instances of 
ENLISTED object may be associated with a single instance of 
EBILLET object. 
(3) Personnel Objects. Members of the Armed 

Forces are either Commissioned Officers or Enlisted 
Personnel. Personnel data gleaned from the Officer 
Distribution Control Report (ODCR), the Enlisted 
Distribution Verification Report (EDVR), Permanent Change of 
Station (PCS) orders, Personnel Service Records, and 
personnel data input or change forms (as created and used by 
each activity) is entered into the system to create, modify, 
and delete unique instances of OFFICER and ENLISTED objects. 

Each instance of the OFFICER object is 
identified by the individual’s SSN. This object contains 
the properties of Name, Grade, Projected Rotation Date 
(PRD), and Date of Rank, as well as the object properties of 
DEPARTMENT and DIVISION. The property Collateral Duties may 
be multivalued and describes the non-billet duties assigned 
to an officer such as Urinanalysis Officer or Navy Relief 


Coordinator. The object properties, OFFICER, DEPARTMENT, 


‘More than one Enlisted person may be temporarily assigned to 
an instance of EBILLIT during periods of turnover and reassignment. 
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and DIVISION are single valued, however, the object property 
of OBILLET may be multivalued as an officer may be assigned 
to more than one billet. 

The ENLISTED object is identified by SSN 
for each instance in the database. Other properties in this 
object include Name, Rating, Paygrade, Rate, PNEC, SNEC, 
PRD, End of Active Obligated Service (EAOS) date, Date of 
Rank, and Time in Service. As Enlisted personnel are 
initially assigned to a department and division then to a 
billet, these object properties are included. An enlisted 
member may only be assigned to a single department or 
division at a time but may be assigned to more than one 
billet. The property Collateral Duties is multivalued. 
These non-billet duties may include assignments such as 
Watch Section Leader or Training Petty Officer. 

d. Management Views of Objects 

The Executive level of a command views the 
activity as a collection of DEPARTMENT objects, each of 
which is divided into a collection of DIVISION objects. 
Each of these objects is viewed as containing several 
instances of OBILLET and EBILLET objects. From this level, 
OBILLETs are viewed as containing instances of OFFICER 
object.  Enlisted personnel are viewed as belonging to a 


specific instance of DEPARTMENT or DIVISION object. 
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Lower management levels of a command, i.e., 
Department Heads and Division Officers, view the activity in 
terms of a specific instance of a DEPARTMENT or DIVISION 
object and the OBILLET and EBILLET objects contained 
therein.  OBILLET and EBILLET objects are then viewed as 
containing one or more instances of OFFICER and ENLISTED 
objects, respectively. 

Personnel are viewed as instances of OFFICER or 
ENLISTED objects. At the Executive level, officer personnel 
are viewed as assigned to one or more specific instances of 
OBILLET object, and enlisted personnel to a specific 
instance of DEPARTMENT object or DIVISION object. At the 
Department and Division levels, enlisted personnel are 
viewed as assigned to one or more specific instances of 
EBILLET object. An officer or enlisted individual may be 
temporarily unassigned to a billet or assigned to a billet 


with another individual (see previous footnotes). 


B. FUNCTIONAL REQUIREMENTS 
The AMA/PMS consists of a single application with two 
main processes, the Manage Manpower process and the Create 
Reports process. (Appendix C, Figures C-1 and C-2). 
1. Manage Manpower Process 
This process is divided into two lower level 
processes, Manage Billet Objects and Manage Personnel 


Objects. (Appendix C, Figures C-3 and C-4). 
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a. Manage Billet Objects 
This lower level process contains the mechanisms 

for creating, modifying, and deleting instances of OBILLET 
and EBILLET objects. Using source documents such as the MPA 
(OPNAV 1000/2) or notification letters from Resource 
Sponsors, the user will be able to maintain all billet data 
used by the AMA/PMS. Instances of OBILLET and EBILLET 
objects will be created, modified and deleted in this 
process. Instances of DEPARTMENT and DIVISION objects will 
be created via the Create OBILLET and Create EBILLET 
processes. DEPARTMENT and DIVISION objects can be modified 
and deleted independent of the Update OBILLET and Update 
EBILLET processes. (Appendix C, Figures C-6 through C-10). 

b. Manage Personnel Objects 

Using data gleaned from PCS orders, ODCR, EDVR, 
personnel service records, etc., this process provides the 
mechanisms for managing the personnel data used by the 
AMA/PMS. Instances of the OFFICER and ENLISTED objects will 
be created, modified, and deleted in this process. 
(Appendix C, Figures C-11 through C-14). 
2. Create Reports Process 

The second major component of the AMA/PMS is the 

Create Reports Process. (Appendix C, Figure C-15). By 


using data stored in the database by the Manage Manpower 
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Process, the system generates reports. These reports 
provide various views of the data for use in analyzing an 
activity’s manpower. 

Nine standard report outputs are produced by the 
AMA/PMS. (Appendix C, Figures C-15 thourgh C-21 and 
Appendix D, Figures D-5 through D-11). There are two 
general types of reports generated by the Generate Reports 
process: Manning Reports and Status Reports. 

a. Manning Reports 

Manning Reports provide information linking an 
officer or enlisted member directly to one or more 
authorized billets. The Department/Division Manning Report 
Will be created by drawing required data from instances of 
ENLISTED object, and DEPARTMENT object. Officer Manning 
Report will contain information gleaned from instances of 
OFFICER object and DEPARTMENT object. The Personnel 
Gains/Losses Report will draw on the OFFICER and ENLISTED 
objects to produce a report showing those personnel known to 
be ordered to the activity but not yet received, and those 
personnel whose PRDs are within six months of the date of 
the report. (Appendix D, Figures D-5 through D-7). 

b. Status Reports 

Status Reports provide a numeric overview of an 
activity in terms of billets authorized and personnel 


assigned. The system will focus on various properties within 
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an object depending on the status report being produced. It 
w111 then calculate the number of times that property occurs 
in the instances of an object. 

Flve status reports are generated by the system. 
The Officer Status Report provides information on authorized 
officer billet levels and the number of officer personnel 
assigned to the activity. The Department/Division Status 
Report provides the same comparison for enlisted personnel. 
The Paygrade Status Report is a comparison between the 
number of billets authorized for each enlisted and officer 
paygrade and the number of personnel assigned within each 
paygrade. The Designator/Rating Status Report provides a 
comparison between the number of billets authorized for each 
officer designator and each enlisted rate and the number of 
personnel assigned, broken down by paygrade. (Appendix D, 


Figures D-8 through D-11). 


C. SUMMARY 

This chapter provided a brief overview of Object 
Oriented Database Analysis methodology. Data requirements 
for the AMA/PMS are presented as Objects in Appendix A, and 
defined in Object Specifications presented in Appendix B. 
Function requirements for the system, the data used in these 
processes and, the objects created and used were examined in 
detail. Data Flow Diagrams (DFD) for the AMA/PMS are 


presented in Appendix C. 
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Chapter IV will present the logical database design 
using Object Oriented methodology and the Relational 


Database Model. 
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IV. DATABASE DESIGN 


In Chapter III the functional and data requirements for 
the AMA/PMS were specified. Using an object oriented 
database methodology, the entities in the user's environment 
are represented as objects to be stored in the database. 

The functional requirements of the system are represented by 
data flow diagrams showing how objects are created, 
modified, deleted, and displayed and who is authorized to do 
what on these objects. 

In this chapter, the logical database and application 
design are presented. In the logical design phase, database 
objects, as defined in the user's requirements phase, are 
transformed into a relational diagram. In the application 
design phase, menu structures, detailed forms and reports, 
and pseudo code for application programs are developed for 
the data flow diagrams developed in the user's requirement 


phase. 


A.  LOGICAL DATABASE DESIGN 
1. Relational Database Model 
The Relational Database Model is the approach used 
to organize the data in the logical design. "The relational 


database model is based on the concept that data is stored 
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(at least conceptually) in two-dimensional tables called 


relations. Each row in the table represents a record", 


i.e., an instance of an entity. "Each column represents a 
field" or characteristic of an entity. ". . . A column is 
called an attribute". (Ref. 4:Chap 5]. Each table is 


generally referred to as a file. 

There are restrictions placed on relations, however. 
"First, attributes are single valued; neither repeating 
groups nor arrays are allowed. Second, entries in any 
column are all of the same kind". (Ref. 4:Chap 5]. For 
example, for each record (row) in a file (table) there would 
be only a single entry in the column (attribute) called 
‘age’. No two records in a file may be identical. 

2. Object Relationships 

First, in order to convert objects into relations, 
the analyst examines the relationships among the objects and 
constructs a preliminary relational diagram. It should be 
noted that there is not necessarily a one to one correlation 
when converting objects into relations. Next, all relations 
are normalized to eliminate modification anomalies. 
Additional relations will need to be created to to 
accomplish normalization. 

The relationships between relations are determined 
from the types of objects from which they are derived. 


These relationships are classified as one to one, one to 
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many, and many to many, and apply only to the relationship 
between any two relations. Relationships between relations 
further are designated as elther mandatory or optional. 

In a one to one relationship, the key of either 
relation is placed into the other as a foreign key. In a 
one to many (parent to child) relationship, the key of the 
parent is placed into the child relation as a foreign key. 
An intersection relation is created to represent a many to 
many relationship. The key of an intersection relation is 
the composite key of both of the parent relations. 

3. Relational Diagram 

From the Object Diagram and Object Specifications 
defined in Chapter III and Appendices A and B, relations and 
relation definitions are produced. Appendix E is the 
Relational Diagram for the AMA/PMS. It graphically 
represents the relationships between relations as derived 
from the Object Diagrams in Appendix A. Appendix F contains 
the Relation Definitions and the physical description of the 
Domain Definitions only. 

All of the objects defined for the AMA/PMS, Appendix 
A, are compound objects. Each contains at least one object 
property which is either single or multi-valued. The 
OFFICER and ENLISTED objects are, additionally, composite 
objects as they contain a multi-valued, non-object property. 


The intersection relation DIVASSIGN is created to represent 
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the many to many relationship between DIVISION and OFFICER. 
The intersection relations OASSIGN and EASSIGN were defined 
in order to represent the many to many relationship between 
the compound objects; OFFICER and OBILLET, and ENLISTED and 
EBILLET, respectively; which contain each other as object 
properties. The relation COLDUTIES was created to 
illustrate the composite object relationships between 
OFFICER and ENLISTED and their multi-valued, non-object 
property COLDUTY. (Appendix E). 

In the Relational Diagram, Appendix E, the key for 
each relation is indicated by an underlined attribute. A 
foreign key is identified by an asterisk. The key for an 
intersection relation is the key for each of the parent 
relations, indicated by an underline and an asterisk. A 
mandatory relationship is represented by a bar on the 
connecting line and an optional relationship by a circle. 

4. Normalized Relations 

All relations in the AMA/PMS are in Boyce-Codd 
Normal Form. The relations have been developed to avoid 
modification anomalies which are undesirable consequences 
resulting from changing the data in relations. There are 
three types of modification anomalies: deletion, insertion, 
and update. 

A deletion anomaly is caused when deletion of the 


facts about one entity inadvertently causes the deletion of 
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facts about another entity. For example, if, in the 
AMA/PMS, an officer record is deleted and a billet record is 
also mistakenly deleted this is a deletion anomaly. 

An insertion anomaly would exist if, for example, a 
billet record could not be entered into the database until 
an officer or enlisted person was assigned to the billet. 
This should result in an incomplete database for billet 
structure. 

An update anomaly occurs when redundancy of data is 
required based on the database structure. For example, if 
an individual is assigned to more than one billet and a 
separate record on the individual is created in the file for 
each billet held. If data needed to be changed on the 
individual, such as rank, then for each billet record on the 
individual, a change would have to be made. This requires 
too much record updating for a simple data change. 

To solve these anomalies, using the above examples, 
three relations would be created; one containing personal 
information on an individual and one containing billet 
information, and an intersection relation linking an 


individual to a specific billet(s). 
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B. RELATIONSHIP DESCRIPTIONS 
1. DEPARTMENT 

The DEPARTMENT object is a compound object as it 
contains the object properties of DIVISION, OFFICER, 
ENLISTED, OBILLET, and EBILLET. All are multi-valued. 
Because DEPARTMENT is a compound object, the key to this 
relation, DName, is placed as a foreign key in each of its 
child relations. All of the relationships between 
DEPARTMENT and its child relations are one to many. A 
DEPARTMENT may have multiple values of DIVISION, OFFICER, 
ENLISTED, OBILLET, and EBILLET. Each of these child 
relations 1S, however, associated with only one DEPARTMENT. 

a. DEPARTMENT and DIVISION 

The relationship between DEPARTMENT and DIVISION 

is mandatory/optional. A DIVISION must belong to a 
DEPARTMENT, but a DEPARTMENT may not have any DIVISIONS 
asSigned, such as the Safety Department in an aviation 
squadron. 

b. DEPARTMENT and OFFICER 

The relationship between DEPARTMENT and OFFICER 

is mandatory/optional. An OFFICER must be assigned to a 
DEPARTMENT, but a DEPARTMENT might not necessarily have an 
OFFICER assigned at all times or may have several OFFICERS 


assigned. 
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c. DEPARTMENT and ENLISTED 
The relationship between DEPARTMENT and ENLISTED 
is the same as that for OFFICER, one to many and 
mandatory/optional. 
d. DEPARTMENT and OBILLET 
The relationship between DEPARTMENT and OBILLET 
is mandatory/mandatory as all DEPARTMENTS must have at least 
one OBILLET assigned and an OBILLET is always associated 
with a DEPARTMENT. 
e. DEPARTMENT and EBILLET 
Between DEPARTMENT and EBILLET, however, the 
relationship is mandatory/optional. An EBILLET must be 
associated with a DEPARTMENT, but a DEPARTMENT need not have 
any or may have several EBILLETS assigned. 
2. DIVISION 
DIVISION is a compound object containing the object 
properties OFFICER, ENLISTED, OBILLET and EBILLET. Each of 
these object properties is multi-valued. The key to the 
DIVISION relation, DivName, is placed as a foreign key in 
each of its child relations. 
a. DIVISION and OFFICER 
The relationship between DIVISION and OFFICER can 


be many to many.’ This relationship is illustrated through 


"This is not often done and usually is a result of manning 
shortfalls. 
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the creation of an intersection relation called DIVASSIGN. 
Its key is the composite key, DivName and SSN (SSN is the 
key to OFFICER). More than one OFFICER may be assigned to a 
DIVISION, optional relationship, and an OFFICER may be 
assigned as a Division Officer to more than one DIVISION 
(also an optional relationship). 
b. DIVISION and OBILLET 

The relationship between DIVISION and OBILLET is 
optional/optional. A DIVISION (or workcenter) need not have 
OBILLETs associated with it, for example the Career 
Counseling Division, and an OBILLET may be assigned only to 
a DEPARTMENT and not a DIVISION. 

C. DIVISION and ENLISTED/EBILLET 

DIVISION is related to both ENLISTED and EBILLET 
in a one to many, mandatory/optional relationship. An 
ENLISTED must be assigned to a DIVISION, although it is 
possible that a DIVISION has no ENLISTED associated. Many 
ENLISTED may be assigned to a DIVISION, but an ENLISTED 
person is generally assigned to only one DIVISION.’ 

EBILLET must be associated with DIVISION, however 


DIVISION need not contain EBILLETs. 


'A Department Head is not necessarily a Division Officer. 


"AS stated previously, billets may be assigned to a Department 
for administrative support. 
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3. OFFICER and OBILLET 

OFFICER is a composite and compound object. OFFICER 
contains Collateral Duties as a multi-valued, non-object 
property. This relationship is illustrated by the COLDUTY 
relation. The composite key of this relation is SSN from 
OFFICER and Colduty. Certain collateral duties must be 
assigned to OFFICER, but not all OFFICERs are required to 
hold collateral duties. Thus the mandatory/optional 
relationship. 

OFFICER contains OBILLET as a multi-valued object 
property, and OBILLET contains OFFICER in the same manner. 
This creates compound objects with a many to many 
relationship. In order to avoid update anomalies, an 
intersection relation called OASSIGN is created. Its key is 
the composite key, SSN and BSC (BSC is the key for OBILLET). 
An OFFICER may be assigned to more than one OBILLET or none 
at all.  OBILLET may be allotted to more than one OFFICER or 
to none at all.” 

4. ENLISTED and EBILLET 

ENLISTED is a composite and compound object. 
ENLISTED contains Collateral Duties as a multi-valued, non- 
object property. This relationship is illustrated by the 


COLDUTY relation. The composite key of this relation is SSN 


ÜÉFor a period of time two officers may be assigned to the same 
billet if one is relieving (replacing) the other. A billet may be 
gapped (unfilled) during manning shortfalls. 
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from ENLISTED and Colduty. Certain collateral duties must 
be assigned to ENLISTED but not all ENLISTEDs are required 
to hold collateral duties. Thus the mandatory/optional 
relationship. 

ENLISTED contains EBILLET as a multi-valued object 
property, and EBILLET contains ENLISTED in the same manner. 
This creates compound objects with a many to many 
relationship. In order to avoid update anomalies, an 
intersection relation called EASSIGN is created. Its key is 
the composite key, SSN and BSC (BSC being the key for 
EBILLET). An ENLISTED may be assigned to more than one 
EBILLET or not at all. EBILLET may be allotted to more than 


one ENLISTED or none at all.! 


C. APPLICATION DESIGN 

The application design phase is the final step in 
logical database design. First, the number of applications 
and application scope are determined. For the AMA/PMS, 
there are two applications, Manpower Management and Reports. 
The Manpower Management application uses all object views 
specified in Appendix A for data entry, modification, 
display, and deletion. The Reports application manipulates 


the data within the database to produce either predefined 


For a period of time two enlisted personnel may be assigned 
to the same billet if one is relieving (replacing) the other. A 
billet may be gapped (unfilled) during manning shortfalls. 
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reports or respond to user ad hoc queries. The application 
design process entails materialization of objects into data 
input and display/modify screens and output design. Data 
outputs are in the form of predefined reports, Appendix D. 
The scope of the application is specified in Appendix G, 
Update, Display and Control Mechanisms. 
1. Menu Hierarchy 

Access to the two AMA/PMS applications will be menu- 
driven for ease of use. The menu hierarchy, Appendix H, 
consists of three layers below the Main Menu. The Main Menu 
provides initial access to either application, Manpower or 
Reports. Design materializations, input and display/modify 
Screens, and menu logic are presented in Appendices D and I, 
respectively. 

a. Manpower Menu 

The Manpower Menu, provides access to the next lower 
menu layer through either of two paths; Billet Data or 
Personnel Data. 

CH) Billet Data Menu. The Billet Data Menu 
offers the user the choice to Add New Billet data, Edit 
Billet Data, or Delete an existing billet record. Any of 
these three choices leads to the next lower menu layer. If 
the user desires to Add New Billet data the system, through 
the Billet Type Menu, will allow the choice of either an 


Officer or Enlisted Billet data input screen. Selection of 
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the Edit Billet Data or the Delete Billet option leads to a 
menu which will allow a choice of three Billet Display 
formats; by Department, Division, or Billet Sequence Code 
(BSC). 

The Billet Data Menu also provides direct 
access to the Personnel Data Menu and to the Reports 
application menu, without requiring the user to return to 
the previous menu layer; and allows the user to return to 
the Manpower Menu. The Billet Type and Billet Display menus 
allow the user to return only to the Billet Data Menu. 

(2) Personnel Data Menu. The Personnel Data 
Menu presents the user with the choice to Add New Personnel 
data, Edit Personnel Data, or Delete Personnel data. If the 
user chooses to Add New Personnel an additional menu will 
provide the user the choice of the Officer or Enlisted 
Record Type input screen. The Record Type menu allows the 
user to return only to the Personnel Data menu. 

The Personnel Data Menu also provides 
direct access to the Billet Data Menu and to the Reports 
application menu, without requiring the user to return to 
the previous menu layers; and allows the user to return to 
the Manpower Menu. 

b. Reports Menu 
The Reports Menu, provides direct selection of 


the Gains/Losses Report and/or access to the next lower menu 
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layer through either of two paths; Manpower Reports or 
Status Reports. Additionally, the user may request Ad Hoc 
queries against the data base. All reports will be 
displayed on screen and provide the user the option to print 
the specified report. 

(1) Manpower Reports Menu. This menu provides 
the user the option of displaying activity enlisted manpower 
information either by Department or Division. A report of 
the activity officer manpower is also an option. 

The Manpower Reports menu provides direct 
access to the Status Reports Menu or to the Manpower Menu as 
well as the previous menu. 

(2) Status Reports Menu. This menu presents 
the user with four options for activity enlisted personnel 
status reports; by Department, Division, Paygrade, or 
Designator/Rate. Officer Status Reports is an additional 
menu option. 

The user ls provided direct access to the 
Manpower Reports and Manpower Menus as well as the option to 


return to the Reports Menu. 


D. CONTROL MECHANISMS 

The AMA/PMS database will contain information protected 
under the Privacy Act as well as Combat Readiness related 
information. It therefore must be protected by a computer 


security system that as a minimum consists of password 
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access controls. Additional controls on the system consist 
of data integrity requirements. Data integrity will be 
validated against tables which have specified allowable 
values for data elements such as Rate/Rank, Designator, 
PNEC/SNEC, and BSC. The presence of data in Name, SSN, PRD, 
EAOS, etc. fields will be the control mechanism for these 
data elements. The field for Collateral Duties will be a 
free-form comments field. Update, Display and Control 
Mechanisms are specified in detail in Appendix G. 
1. Data Input 
a. Billets 

All fields on the Officer Billet Input screen are 
mandatory. With the exception of the PNEC and SNEC fields 
on the Enlisted Billet input screen, all fields are 
mandatory. 

b. Personnel 

Mandatory fileds on officers are first and last 
names, Grade Designator, SSN, and PRD. For enlisted 
personnel the mandatory fields are first and last name, SSN, 
Rating, paygrade, Rate, and PRD. All other fields for both 
inputs are optional. 

Billet assignments are either made through the 
input mode for personnel records or by modifying an existing 


record. 
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2. Data Display, Modification, or Deletion 
a. Billet 
Billet data may be displayed on the screen by 
specifying Department or Division. The user then scrolls 
through the data as needed. Billet data may also be 
displayed by specifying BSC. Once displayed, billet data 
may be modified on screen or deleted from the database. 
b. Personnel 
Personnel data may be displayed on the screen by 
specifying the personnel record desired by SSN or by Name 
and Grade/Rating combination. Once displayed, personnel 
records may be modified or deleted from the database. 
c. Reports 
All pre-defined report formats will be displayed 
on screen. Information in the reports cannot be modified or 


deleted from the reports process. 


E. SUMMARY 

This chapter presented the logical database design for 
the AMA/PMS using Object Oriented Database Design 
methodology and the Relational Database Model. A11 objects 
specified in Appendix A, were transformed into normalized 
relations. These relations contain no modification 
anomalies. The relationships between these relations are 
illustrated in Appendix E and described in Section B of this 


chapter. Database control mechanisms are described in 
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Appendix G. Input/Display screens, Menu Hierarchy and menu 
samples, and menu logic (pseudo code) are presented in 


Appendices D, H, and I, respectively. 
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V. SUMMARY AND CONCLUSIONS 


A. SUMMARY 

With ever increasing DOD budget cuts, the need to 
actively manage limited manpower assets is vital to 
successful accomplishment of the Navy’s mission. The 
information needed for manpower analysis at the activity 
level is readily available in documents published by higher 
authority: MPA, ODCR, and EDVR. However, this information 
is rarely used to manage manpower because of a lack of 
knowledge on the part of COs, XOs, Department Heads, and 
Division Officers on the mechanisms and importance of the 
process. 

Failure to manage manpower at the activity level can 
have serious negative impact on mission/combat readiness. 
Conversely, proactive manpower analysis can avert serious 
manning shortfalls. 

Object oriented methodology was used to fully define 
functional and data requirements. Data requirements are 
presented in Appendix A, Object Diagrams; and Appendix B, 
Object Definitions. Dataflow diagrams for the AMA/PMS are 


presented in Appendix C. System output/report formats are 
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presented in Appendix D. Functional requirements are 
described in Appendix G, Update, Display, and Control 
Mechanisms. 

The Relational Database Model was used as a design tool. 
Objects were transformed into relations in Boyce-Codd Normal 
Form, thereby eliminating all possible modification 
anomalies. The design specifications are presented in 
Chapter IV. The Relational Diagram and Relation Definitions 
are presented in Appendices E and F, respectively. The 
AMA/PMS is designed to be menu driven. The Menu Hierarchy 
and Menu Logic (pseudo code) are contained in Appendices H 


and I. 


B. ALTERNATIVE FUNCTIONALITY 

The AMA/PMS is designed strictly to manage activity 
level active duty military manpower. The design can easily 
be modified, after requirements have been specified, to 
accommodate civilian and/or reserve manpower. 

Additional functionality could be gained by designing 
system interfaces to allow mainframe to personal computer 
down-load of billet information from NMDAS, enlisted 
personnel data from NES, and officer personnel data from 
OPINS. Some modification of domain definitions would be 
required to ensure data compatability. This would 


significantly reduce data input time to the database. 


60 


DEPARTMENT 


DName 


EBILLET 


BSC 
Billet Title 


"DEPARTMENT 


DIVISION 
ENLISTED ` 


MV 


Flgure 


APPENDIX A: 


A-1: 


DIVISION 


DivName 
DEPARTMENT 


MV 
¿ENLISTED 
MV 


MV 
MV 





OFFICER 


Designator 

PRD 

Date of Rank 
Collateral Duties 
-DEPARTMENT 
DIVISION 


'OBILLET 


61 


OBJECT DIAGRAMS 
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APPENDIX B: OBJECT DEFINITIONS 


A. OBJECT DEFINITIONS 


‘Ls 


Department Object 

DName; Department name 

DIVISION; DIVISION object; MV; SUBSET {DivName, 
OBILLET, EBILLET} 

OFFICER; OFFICER object; MV; SUBSET {Name, Grade, 
Designator, PRD} 

ENLISTED; ENLISTED object; MV; SUBSET {Name, Rating, 
Rate, Rank, PNEC, SNEC, PRD, EAOS} 

OBILLET; OBILLET object; MV; SUBSET {BSC, Billet 
Title, Grade, BA} 

EBILLET; EBILLET object; MV; SUBSET {BSC, Billet 
Title, Rating, BA} 

Division Object 

DivName; Division name 

DEPARTMENT; DEPARTMENT object; SUBSET {DName} 

OFFICER; OFFICER object; MV; SUBSET {Name, Grade, 
Designator, PRD} 

ENLISTED; ENLISTED object; MV; SUBSET {Name, Rating, 
Rate, Rank, PNEC, SNEC, EAOS} 

OBILLET; OBILLET object; MV; SUBSET {BSC, Billet 


Title, Grade, BA} 
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EBILLET; EBILLET object; MV; SUBSET (BSC, Billet 
Title, Rating, BA) 

Obillet Object 

BSC; Blllet Sequence Code 

Billet Title; Name of billet 

Grade; Officer rank required for billet 

Designator; Warfare speciality required for billet 

BA; Billet Authorization, number of billets 
authorized; MV 

DEPARTMENT; DEPARTMENT object; SUBSET {DName} 

DIVISION; DIVISION object; SUBSET {DivName} 

OFFICER; OFFICER object; MV; SUBSET {Name, Grade, 
Designator, PRD} 

Ebillet Object 

BSC; Billet Sequence Code 

Billet Title; Name of billet 

Rating; Technical speciality required for billet 


Paygrade; Paygrade required for billet 


Rate; Alpha-numeric combination of Rating 
and Paygrade required for billet 
PNEC; Primary Naval Enlisted Classification Code 
SNEC; Secondary Naval Enlisted Classification Code 
BA; Billet Authorization, number of billets 
authorized; MV 


DEPARTMENT; DEPARTMENT object; SUBSET {DName} 
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DIVISION; DIVISION object; SUBSET (DivName) 

ENLISTED; ENLISTED object; MV; SUBSET (Name, Rating, 
Rank, Rate, PNEC, SNEC, PRD) 

Officer Object 

SSN; Officer's Social Security Number 

Name; Officer’s full name 

Grade; Officer’s Rank 

Designator; Warfare designator 

PRD; Projected Rotation Date 

Date of Rank; date promoted to current rank 

Colduties; Comments or collateral duties; MV 

DEPARTMENT; DEPARTMENT object; SUBSET {DName} 

DIVISION; DIVISION object; SUBSET {DivName}; MV 

OBILLET; OBILLET object; MV; SUBSET {bsc, billet 
title} 

Enlisted Object 

SSN; Enlisted's Social Security Number 

Name; Enlisted's full name 

Rating; Individual'/s technical speciality 

Paygrade; Individual's paygrade 

Rate; Alpha-numeric combination of individual's 
Rating and Paygrade 

PNEC; Primary Naval Enlisted Classification Code 

SNEC; Secondary Naval Enlisted Classification Code 

PRD; Projected Rotation Date 


EAOS; Date - End Active Obligated Service 
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Date of Rate; date promoted to current rate 

Time in Service; Number of years, months, days 
enlisted in Navy 

Colduties; Comments or collateral duties; MV 

DEPARTMENT; DEPARTMENT object; SUBSET {DName} 

DIVISION; DIVISION object; SUBSET (DivName) 

EBILLET; EBILLET object; MV; SUBSET (bsc, billet 


tltle) 


DOMAIN DEFINITIONS 


1. 


ba: 

Numeric 4 

Number of Billets Authorized 

billet title: 

Text 20 

Title of authorized billet as it appears on the 
OPNAV 1000/2 

bsc: 

Numeric 5 

Billet Sequence Code as it appears on the OPNAV 
1000/2 

cob: 

Numeric 4 

Number of personnel Currently on Board 

date: 


Numeric, mask yymmdd, 


66 


10. 


11. 


p 


where yy is any 2 digits, mm is any 2 digits from 
01 to 12, dd is any 2 digits from 01 to 31. 

date of rank: 

Same as number 5 above 

date of rate: 

Same as number 5 above 

designator: 

Numeric 4 

Four digit code representing an Officers warfare 

specialty 

divname: 

Text 15 

Name of a division as it appears on the OPNAV 1000/2 

dname: 

Text 15 

Name of a department as it appears on the OPNAV 

1000/2 

grade: 

Text 4, mask XXXX 
where XXXX ls one of: FADM, ADM, VADM, RAMU, 
RAML, CAPT, CDR, LCDR, LT, LTJG, ENS, CWO4, CWO3, 
CWO2 


Grade tltle of a Comlssioned Officer 


name: 


text 40: Mask: 
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J. 


14. 


15. 


16. 


17. 


flrst name; Text 15 
mi; Text 2 
last name; Text 23 
Full name of all personnel assigned 
nec: 
Numeric 4 
Naval Enlisted Classification Code as found in the 
NEC Manual or on the OPNAV 1000/2 (used for Primary 
and Secondary NEC (PNEC/SNEC)) 
paygrade: 
Text 5, mask XXXXX, 
where XXXXX is one of:E9, E8, E7, E6, E5, E4, 
E1-E3 
Paygrade of Enlisted Personnel 
pnec: 
Numeric 4 
See NEC above. 
pob: 
Numeric 4 
Projected on Board number of personnel 
prd: 
Text 5, mask AYYMM 
where A indicates that an individual is has not 
yet arrived on board (otherwise this digit is 
blank), YY is any 2 digits from OO to 99, and MM 


is any two digits from 01 to 12 
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18. 


po 


20. 


2l. 


Projected Rotation Date of personnel assigned 

rate: 

Text 5, mask XXXZZ 
where XXX is enlisted rate and ZZ is one of: 1, 
npo MES. EM 

Enlisted rating, combination of enlisted technical 

specialty and rate 

rating: 

Text 3, mask XXX 
where XXX is an enlisted speciality rating as 
found in the NEC Manual. 

snec: 

Numeric 4 

See NEC above. 

ssn: 

Numeric 9 

Personnal identification number assigned by the 


Social Security Administration 
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APPENDIX C: DATAFLOW DIAGRAMS 
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Figure C-1:  AMA/PMS 
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Figure C-2: Manage Manpower and Create Reports Processes 


Diagram 
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Figure C-3: Manage Manpower (Update Objects) 
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Figure C-4: Manage Objects 
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Figure C-5: Update DEPARTMENT and DIVISION Objects 
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Figure C-6: Add, Modify, and Delete DEPARTMEMT Object 
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Figure C-7: Add, Modify, and Delete DIVISION Object 
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Figure C-8: Update OBILLET and EBILLET Objects 
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Figure C-9: Add, Modify, and Delete OBILLET Object 
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Figure C-12: Add, Modify, and Delete OFFICER Object 
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Figure C-16: Create Enlisted Reports 


85 


Command 
Career 
Counselor 


Department Executive Manpower Division 


Head Officer Analyst 


Officer 














Division 
Manning 
Report 
ENLISTED 
Object 
CREATE 
ENLISTED 
MANNING Database 
REPORTS 
DEPARTMENT 
Object 
Department 
Manning 
Report 


Command Department Executive Manpower 


Career Head Officer Analyst 
Counselor 





Figure C-17: Create Enlisted Manning Reports 
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Figure C-18: Create Enlisted Status Reports 


87 


Database 


OFFICER DEPARTMENT 
Object Object 










CREATE 
OFFICER 
REPORTS 


Officer Status f 
ws Em Officer Manning Report 


Commanding Executive 


Manpower Department 
Officer Officer 


Analyst Heads 





Figure C-19: Create Officer Reports 
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APPENDIX D: SAMPLE FORMS AND REPORTS 


ENLISTED PERSONNEL DATA INPUT/CHANGE FORM 





Last Name First Name 
Rating Paygrade Rate 
PNEC SNEC SSN PRD TIR 


Comments (Colaterial Duties, Watch Section, Qualifications) 


(Enter RATING and PAYGRADE; system will enter RATE) 


BILLET ASSIGNMENT 


Department Division 
BSC Billet Title 


BILLET ASSIGNMENT 


Department Division 
BSC Billet Title 


TIS 


Do you wish to add, modify or delete another Enlisted Record? (A/M/D/NO) 


Figure D-1: Enlisted Personnel Data Input/Change Form 
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ENLISTED BILLET DATA INPUT/CHANGE FORM 








Department Division 

BSC Billet Tite — Rating Paygrade 
Rate PNEC SNEC - 

BA — FY+1 FY42 FY+3 FY+4 FY+5 


(Enter RATING and PAYGRADE; system will enter RATE) 


Do you wish to add, modify, or delete an Enlisted Billet? (A/M/D/NO) 


Figure D-2:  Enlisted Billet Data Input/Change Form 
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OFFICER PERSONNEL DATA INPUT/CHANGE FORM 


Last Name First Name MI 





Grade Desig SSN PRD DOR 


Comments (Colaterial Duties, Watch Section, Qualifications) 


BILLET ASSIGNMENT 
Department — Division 
BSC” Billet Title 
BILLET ASSIGNMENT 
Department | Division 
BSC | Billet Title 


Do you wish to add, modify, or delete another Officer Record? (A/M/D/NO) 


Figure D-3: Officer Personnel Data Input/Change Form 
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OFFICER BILLET DATA INPUT/CHANGE FORM 














Department Division 
BSC Billet Title Grade Desig 
BA FY+1 FY+2 FY+3 FY+4 FY+5 


Do you wish to add, modify, or delete an Officer Billet? (A/M/D/NO) 


Figure D-4: Officer Billet Data Input/Change Form 
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DEPARTMENT MANNING REPORT 


DEPARTMENT: OPERATIONS 


BSC BILLET RATE PNEC 
TITLE SNEC 

30060 Signalman SM1 

30070 Signalman SM2 


DEPARTMENT: OPERATIONS 


55060 Boatsmate BM1 


55070 BM Basic SN 9700 


DIVISION: F DIVISION 


BA NAME RATE PNEC 
SNEC 
1 Jones, R. SM1 
2 Petty, T. SM2 
Kart, E. SM3 


DIVISION: DECK DIVISION 


1 Kennedy, C BM1 


28 Jones, L. BMSN 


Cathcart, M. SN 


REPORT DATE 


PRD/ 


9203/ 


9406 


9212/ 
9406 


9303/ 
9406 


DIVISION MANNING REPORT 
DEPARTMENT: OPERATIONS 


BSC BILLET RATE PNEC 
TITLE SNEC 
30060 Signalman SMI 
30070 Signalman SM2 
Figure D-5: 


REPORT DATE 
DIVISION: F DIVISION 


BA NAME RATE PNEC 
SNEC 

1 Jones, R. SM1 

2 Petty, T. SM2 


Department/Division Manning Report 
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PRD/ 
EAOS 


9203/ 
9406 


9212/ 
9112 


OFFICER MANNING REPORT 
DEPARTMENT: OPERATIONS 


BSC BILLET GRADE/DESIG BA 
TITLE 
30060 OPS Officer LCOR 1300 1 


DIVISION: SCHEDULES 


30070 Scheduler LT 1300 


DIVISION: DET 6 


30080 DET OIC LCOR 1300 


DEPARTMENT: ADMINISTRATION 


55070 ADMIN Officer LCOR 1300 


55075 Legal Officer LT 1100 


NAME 


Jones, R. 


Petty, T. 


Kart, E. 


Jones, L. 


Cathcart, M. 


* 


* 


REPORT DATE 


GRADE/DESIG 


LCOR 1300 


LTJG 1305 


LCDR 1300 


LCDR 1300 


LT 1105 


Figure D-6: Officer Manning Report 
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PRD 


9406 


M 


9303 


9212 


9303 


GAINS / LOSSES REPORT REPORT DATE 


GAINS 

NAME GRADE DESIG EDA 
RATE PNEC 

Jones, R. LT 1300 9002 

Smith, M. ENS 1100 9010 

Carry, D. ADCS 9008 

LOSSES 

NAME GRADE DESIG PRD 
RATE PNEC 

Calloway, T. COR 1300 9003 

Mello, C. LTJG 1310 9005 


Figure D-7: Gains/Losses Report 
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DEPARTMENT STATUS REPORT REPORT DATE 


DEPARTMENT: MAINTENANCE 
DIVISION: MAINT/PROD CTL 


BSC X BILLET RATE PNEC BA COB POB1 POB2 POBS POB4 
TITLE SNEC 


— 
A 
— 
— 
—A 


16050 Maint Coord ATCM 8300 1 
16060 Maint Prod ATCS 2 2 2 3 3 2 


DIVISION: QUALITY ASSURANCE 


18060 QAREP ADI 8318 2 1 1 2 2 2 
18070 QA REP AMH1 8380 2 3 3 3 2 2 
DIVISION: MATERIAL CONTROL 
19060 MTL CLK AK1 3 3 3 2 2 2 
DIVISION STATUS REPORT REPORT DATE 
DEPARTMENT: MAINTENANCE 
DIVISION: POWER PLANTS] 
BA BILLET RATE PNEC BA COB POBi POB2 POBS POR 
TITLE SNEC 
22070 P/P Repairman AD2 8380 6 5 5 5 5 4 
22080 P/P Repairman AD3 8318 3 4 4 4 3 3 


Figure D-8:  Department/Division Status Report 
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OFFICER STATUS REPORT 
DEPARTMENT: SAFETY 


BSC BILLET GRADE/DESIG 
14010 AV Safety LT 311 
14020 AV Safety Asst TIEM 
14030 AV Safety Asst ENS 1321 


DEPARTMENT: MAINTENANCE 
DIVISION: MAINT/PHOD CTL 


16010 A/C ORGMNT ENS 1311 


DIVISION: MAINT ADMIN 


17010 A/C ORGMNT ENS 1311 


BA COB 


— — n 


REPORT DATE 


POB1 POB2 POB3 POB4 


Figure D-9: Officer Status Report 
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APPENDIX F: RELATION DEFINITIONS 


A. RELATION AND KEY DEFINITIONS 
1. OFFICER (SSN, Name, Grade, Designator, PRD, Date of 
Rank, DName, DivName) 
Key: SSN 
Foreign Keys: DName, DivName) 
2. ENLISTED (SSN, Name, Rating, Paygrade, Rate, PNEC, 
SNEC, PRD, EAOS, Date of Rate, Time in Service, 
DName, DivName) 
Key:  SSN 
Foreign Keys: DName, DivName) 
3. DEPARTMENT (DName) 
Key:  DName 
4. DIVISION (DivName, DName) 
Key: DivName 
Foreign Key:  DName 
5. OBILLET (BSC, Billet Title, Grade, Designator, 
BA(CUR), BA(FY1), BA(FY2), BA(FY3), BA(FY4), 
DName, DivName) 
Key: BSC 
Foreign Keys: DName, DivName 
6. EBILLET (BSC, Billet Title, Rating, Paygrade, Rate, 


PNEC, SNEC, BA, DName, DivName) 
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Key: BSC 

Foreign Keys: DName, DivName 
OASSIGN (BSC, SSN) 

Key: BSC, SSN 

EASSIGN (BSC, SSN) 

Key: BSC, SSN 

COLDUTY (SSN, Collaterial Duties) 


Key: SSN, Collaterial Duty 


DOMAIN DEFINITIONS 


10. 


BA IN NUM(4) 

Billet Title IN CHAR(20) 

BSC IN NUM(5) 

COB IN  NUM(4) 

Date IN YYMMDD, YY - 00-99; 


MM = 1=—12o; DD = 1531 
Date of Rank IN YYMMDD, YY = 00-30; 

MM = 0-11; DD = 0-30 
Date of Rate IN YYMMDD, YY = 00-30; 


MM = 0-11; DD = 0-30 


Designator IN NUM(4) 
DivName IN CHAR(15) 
DName IN CHAR(15) 
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11. 


12 


13 


14. 


JE 


l6. 


175 


18. 


TO 


20. 


21. 


Grade 


Name 
NEC 


Paygrade 


PNEC 
POB 


PRD 


Rate 


Rating 


SNEC 


SSN 


IN 


IN 


IN 


IN 


IN 


IN 


IN 


IN 


IN 


IN 


IN 
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CHAR(4); FADM, ADM, VADM, 
RDMU, RAML, CAPT, CDR, 
LCDR, LT, LTJG, ENS, CWO4, 
CWO3, or CWO2 

CHAR(40) 

NUM(4) 

CHAR(5); E9, E8, E7, E6, 
E5, E4, E1-E3 

NUM (4) 

NUM (4) 

NUM(5); YYMM, A - "A" or 
blank, YY - 00-99, 

MM = 01-12 

Char (5) 

CHAR(5); XXXZZ, XXX is any 
enlisted rate and ZZ is one 
of; 12, a Gre CS eN 

NUM (4) 


NUM (9) 


APPENDIX G: 


UPDATE, DISPLAY, AND CONTROL MECHANISMS 


A. UPDATE MECHANISMS 


1. OBILLET Update Mechanisms 


a. 


Add 


(1) 


(2) 


(3) 


(4) 


(5) 


Edit 


1) 


new OBILLET data 


Inputs 

- List of authorized billets from OPNAV 
1000/2 or Notification Letter from the 
appropriate Resource Sponsor. 

Outputs 

- New OBILLET object instance in database. 
Processing notes 

- Data imported enmasse when creating 
database. 

Volume 

- 10 to 500 billets input when creating 
database. 

- Usually less than one per year. 
Frequency 

zmonce per Vear: 

data in OBILLET 

Inputs 

- OBILLET object instance from database 


(including DEPARTMENT properties). 
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(2) 


(3) 


(4) 


(5) 


- OBILLET change data from OPNAV 1000/2 or 
Notification Letter from the appropriate 
Resource Sponsor. 

Outputs 

- Modified object instance to database. 

- Confirmation message on screen. 
Processing notes 

- This function changes all OBILLET data. 
Volume 

- Unpredictable, but changes rarely occur. 
Frequency 


- Once per year. 


Delete OBILLET data 


(1) 


(2) 


(3) 


(4) 


Inputs 

- List of blllets to delete from OPNAV 
1000/2 or Notification Letter from the 
appropriate Resource Sponsor. 

- OBILLET object instance from database. 
Outputs 

- Confirmation message on screen. 
Processing notes 

- Backup of existing object should be made 
prior to deletion. 

Volume 

- Unpredictable, but deletions rarely 


occur. 
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(5) 


2. EBIEEE® 


a. Add 
(1) 
(2) 
(3) 
(4) 
(5) 

b. Edit 


(1) 


Frequency 


- Less than once per year. 


Update Mechanisms 


new EBILLET data 


Inputs 

- List of authorized billets from OPNAV 
1000/2 or Notification Letter from the 
appropriate Resource Sponsor. 

Outputs 

- New EBILLET object instance in database. 
Processing notes 

- Data imported enmasse when creating 
database. 

Volume 

- 20 to 5000 billets input when creating 
database. 

- Usually less than one per year. 
Frequency 

- Once per year. 

data in EBILLET 

Inputs 

- EBILLET object instance from database 
(including DEPARTMENT properties). 

- EBILLET change data from OPNAV 1000/2 or 
Notification Letter from the appropriate 


Resource Sponsor. 
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(2) 


(3) 


(4) 


(5) 


Outputs 

- Modified object instance to database. 

- Confirmation message on screen. 
Processing notes 

- This function changes all EBILLET data. 
Volume 

- Unpredictable, but changes rarely occur. 
Frequency 


- Once per year. 


Delete EBILLET data 


(1) 


(2) 


(3) 


(4) 


(5) 


Inputs 

- List of billets to delete from OPNAV 
1000/2 or Notification Letter from the 
appropriate Resource Sponsor. 

- EBILLET object instance from database. 
Outputs 

- Confirmation message on screen. 
Processing notes 

- Backup of existing object should be made 
prior to deletion. 

Volume 

- Unpredictable, but deletions rarely 
occur. 

Frequency 


- Less than once per year. 
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3. OFFICER Update Mechanisms 


a. 


Add 


(1) 


(2) 


(3) 


n 


(5) 


Edit 


(1) 


new OFFICER data 


Inputs 

- List of new officer personnel from ODCR, 
PCS orders, or personnel input form from 
the Personnel Office. 

Outputs 

- New OFFICER object instance in database. 
Processing notes 

- Data imported enmasse when creating 
database. 

Volume 

- 10 to 500 billets input when creating 
database. 

- Five to 200 per year. 

Frequency 

- Monthly. 

data in OFFICER 

Inputs 

- OFFICER object instance from database 
(including OBILLET properties). 

- OFFICER change data from personnel data 
change form from the Personnel Office or 


the Executive Officer. 


LE 


(2) 


(3) 


(2) 


(5) 


Outputs 

- Modified object instance to database. 

- Confirmation message on screen. 
Processing notes 

- This function changes all OFFICER data. 
Volume 

- Ten officers per month. 

Frequency 


- Monthly. 


cs Delete OFFICER data 


(1) 


(2) 


(3) 


(4) 


(5) 


Inputs 

- List of personnel to delete from the 
check out sheets received from the 
Department Head. 

- OFFICER object instance from database. 
Outputs 

- Confirmation message on screen. 
Processing notes 

- Backup of existing object should be made 
prior to deletion. 

Volume 

- Zero to ten per month. 

Frequency 


- Monthly. 


4. ENLISTED Update Mechanisms 


a. Add new ENLISTED data 
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(1) 


(2) 


(3) 


(4) 


(5) 


Edit 


(1) 


(2) 


(3) 


Inputs 

- List of new enlisted personnel from EDVR 
and PCS orders. 

Outputs 

- New ENLISTED object instance in database. 
Processing notes 

- Data imported enmasse when creating 
database. 

Volume 

- 50 to 5000 billets input when creating 
database. 

- Ten to 1500 per year. 

Frequency 

- Weekly. 

data in ENLISTED 

Inputs 

- ENLISTED object instance from database 
(including EBILLET properties). 

- ENLISTED change data from personnel data 
change form from the Personnel Office or 
the Department Head. 

Outputs 

- Modified object instance to database. 

- Confirmation message on screen. 
Processing notes 


- This function changes all ENLISTED data. 
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(4) 


(5) 


Volume 


- 100 enlisted personnel per month. 
Frequency 


C. Delete ENLISTED data 


(1) 


(2) 


(3) 


(4) 


(5) 


Inputs 

- List of personnel to delete from the 
check out sheets received from the 
Department Head. 

- ENLISTED object instance from database. 
Outputs 

- Confirmation message on screen. 
Processing notes 

- Backup of existing object should be made 
prior to deletion. 

Volume 

- Zero to 100 per month. 

Frequency 


- Weekly. 


5. DEPARTMENT Update Mechanisms 


a. Add new DEPARTMENT data 


(1) 


Inputs 
- New DEPARTMENT list from OPNAV 1000/2 or 
Notification Letter from the appropriate 


Resource Sponsor. 
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(2) 


(3) 


(4) 


(5) 


Edit 


(1) 


(2) 


(3) 


Outputs 

- New DEPARTMENT object instance in 
database. 

Processing notes 

- Data imported enmasse when creating 
database. 

Volume 

- Four to ten departments input when 
creating database. 

- Less than one per year. 

Frequency 

- Less than annually. 

data in DEPARTMENT 

Inputs 

- DEPARTMENT object instance from database 
(including DIVISION properties). 

- DEPARTMENT change data from OPNAV 1000/2 
or Notification Letter from the appropriate 
Resource Sponsor. 

Outputs 

- Modified object instance to database. 

- Confirmation message on screen. 
Processing notes 

- This function changes all DEPARTMENT 


data. 
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(4) 


(5) 


Volume 
- Less than one per year. 
Frequency 


- Less than annually. 


ES Delete DEPARTMENT data 


(1) 


(2) 


(3) 


(4) 


(5) 


Inputs 

- List of departments to delete from OPNAV 
1000/2 or Notification Letter from the 
appropriate Resource Sponsor. 

- DEPARTMENT object instance from database. 
Outputs 

- Confirmation message on screen. 
Processing notes 

- Backup of existing object should be made 
prior to deletion. 

Volume 

- Less than one per year. 

Frequency 


- Less than annually. 


6. DIVISION Update Mechanisms 


a. Add new DIVISION data 


(1) 


Inputs 
- New DIVISION list from OPNAV 1000/2 or 
Notification Letter from the appropriate 


Resource Sponsor. 
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(2) 


(3) 


(4) 


(5) 


Edit 


(1) 


(2) 


(3) 


(a) 


Outputs 

- New DIVISION object instance in database. 
Processing notes 

- Data imported enmasse when creating 
database. 

Volume 

- Five to 50 divisions input when creating 
database. 

- Less than one per year. 

Frequency 

- Less than annually. 

data in DIVISION 

Inputs 

- DIVISION object instance from database 
(including OBILLET and EBILLET properties). 
- DIVISION change data from OPNAV 1000/2 or 
Notification Letter from the appropriate 
Resource Sponsor. 

Outputs 

- Modified object instance to database. 

- Confirmation message on screen. 
Processing notes 

- This function changes all DIVISION data. 
Volume 


- Less than one per year. 
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(5) 


Frequency 


- Less than annually. 


Gi Delete DIVISION data 


(1) 


(2) 


(3) 


(4) 


(5) 


Inputs 

- List of divisions to delete from OPNAV 
1000/2 or Notification Letter from the 
appropriate Resource Sponsor. 

- DIVISION object instance from database. 
Outputs 

- Confirmation message on screen. 
Processing notes 

- Backup of existing object should be made 
prior to deletion. 

Volume 

- Less than one per year. 

Frequency 


- Less than annually. 


B. DISPLAY MECHANISMS 


ie 


OFFICER Display Mechanisms 


a. Query on OFFICER 


(1) 


(2) 


Output Description 
- Form showing all data for an Officer. 
source Data 


- OFFICER object. 
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(3) 


(4) 


(5) 


- DEPARTMENT object. 

- Officer name or SSN keyed in by user. 
Processing Notes. 

- Used by manpower analyst, or other 
authorized user. 

Volume 

- Five per week. 

Frequency 


- Daily. 


Officer Manning Report 


(1) 


(2) 


(3) 


(4) 


(5) 


Output Description 

- Report showing Officer billets authorized 
and the Commissioned Officers assigned to 
them. 

Source Data 

- OFFICER object. 

- DEPARTMENT object. 

Processing Notes. 

- Report produced upon request from user. 
Volume 

- One for each department head, including 
Executive department. 

Frequency 


- Monthly. 
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c. Offlcer Status Report 


(1) 


(2) 


(3) 


(4) 


(5) 


Output Description 

- Report showing Officer billets authorized 
and the number of personnel assigned to 
them. 

Source Data 

- OFFICER object. 

- DEPARTMENT object. 

Processing Notes. 

- Report produced upon request from user. 
Volume 

- One for each department head, including 
Executive department. 

Frequency 


- Monthly 


2. ENLISTED Display Mechanisms 


a. Query on ENLISTED 


(1) 


(2) 


Output Description 

- Form showing all data for an Enlisted 
member. 

Source Data 

- ENLISTED object. 

- DEPARTMENT object. 

- Enlisted member'/s name or SSN keyed in by 


user. 
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(3) 


(4) 


(5) 


Processing Notes. 

- Used by manpower analyst, or other 
authorized user. 

Volume 

- Five per week per department. 
Frequency 


- Daily. 


Department/Division Manning Report 


(1) 


(2) 


(3) 


(4) 


(5) 


Output Description 

- Report showing Enlisted billets 
authorized and the personnel assigned to 
them. 

Source Data 

- ENLISTED object. 

- DEPARTMENT or DIVISION object. 
Processing Notes. 

- Report produced upon request from user. 
Volume 

- One for each department head, including 
Executive department. 

Frequency 


- Monthly. 


123 


c. Department/Division Status Report 


(1) 


(2) 


(3) 


(a) 


(5) 


Output Description 

- Report showing Enlisted billets 
authorized and the number of personnel 
assigned to them. 

Source Data 

- ENLISTED object. 

- DEPARTMENT or DIVISION object. 
Processing Notes. 

- Report produced upon request from user. 
Volume 

- One for each department head, including 
Executive department. 

Frequency 


- Monthly 


3. Combined OFFICER/ENLISTED Display Mechanisms 


a. Designator/Rating Status Report 


(1) 


(2) 


Output Description 

- Report showing the quantity of billets 
authorized by designator and rating, and 
the number of personnel assigned within 
each. 

Source Data 

- OFFICER object. 

- ENLISTED object. 


- DEPARTMENT or DIVISION object. 
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(3) 


(4) 


(5) 


Processing Notes. 

- Report produced upon request from user. 
Volume 

- One for each department, including 
Executive department. 

Frequency 


- Monthly. 


Paygrade Status Report 


(1) 


(2) 


(3) 


(4) 


(5) 


Output Description 

- Report showing the quantity of billets 
authorized by paygrade and the number of 
personnel assigned within each paygrade. 
Source Data 

- OFFICER object. 

- ENLISTED object. 

- DEPARTMENT or DIVISION object. 
Processing Notes. 

- Report produced upon request from user. 
Volume 

- One for each department head, including 
Executive department. 

Frequency 


- Monthly. 
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C. 


Personnel Gains/Losses Report 


(1) 


(2) 


(3) 


(4) 


(5) 


Output Description 

- Report showing the personnel ordered to 
the command but not yet received and 
personnel whose PRD is within three months 
of the report date. 

Source Data 

- OFFICER object. 

- ENLISTED object. 

Processing Notes. 

- Report produced upon request from user. 
Volume 

- One for each department head, including 
Executive department. 

Frequency 


- Monthly 


C. CONTROL MECHANISMS 


1. System Control Mechanisms 


a. 


Provide password system to ensure that only 


authorized users can access for viewing, 


editing, or deleting data. 


Provide verification system to ensure that the 


authorized users have the opportunity to verify 


data prior to an instance of any object being 


Stored in the database. 
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Provide verification system to ensure that the 
authorized users have the opportunity to verify 
data prior to an instance of any object being 
deleted from the database. 

Provide security controls to ensure that data in 
the database cannot be altered from the Reports 


application. 


2. Object Control Mechanisms 


a. 


Provide a set of tables to ensure that only 
authorized data values for Rating, Rate, 
Paygrade, PNEC/SNEC, Grade, Designator, Billet 
Sequence Code, Department and Division Name are 
entered into data fields prior to an instance of 
an object being stored in the database. 

Provide verification system to ensure that 
mandatory fields have values entered prior to an 
instance of an object being stored in the 


database. 


T27 


APPENDIX H: MENU HIERARCHY 





MANPOWER MENU 


1. Billet Data 
2. Personnel Data 
3. Return to Main Menu 


MAIN MENU 
1. Manpower 


2. Reports 
3. Exit to OS 





Coe RSE Ry 


REPORTS MENU 


. Gains/Losses Report 
. Manpower Report 


. Status Report 
. Ad Hoc Queries 
. Retum to Main Menu 
















Ul Nor s 


IDÉES 
eerte MODO DO PER 
ne eo 



























BILLET TYPE MENU 


T | 1. Officer 
2. Enlisted 


BILLET DATA MENU 


1. Add New Billet 
. Edit Billet Data 
. Delete Billet 

. Personnel Data Menu 
Reports Menu 

. Return to Manpower 





3. Return to Billet Data 
Menu 





ONAN 


d (BILLET DISPLAY 
ERSTE REUTERS S , MENU 

1. By Department 
2. By Division 

3. By BSC 

4. Return to Billet Data 
Menu 












PERSONNEL DATA 
MENU 










1. Add New Personnel 3 Ë 
2. Edit Personnet Data = — e n 
3. Delete Personnel A 

4. Billet Data Menu 

5. Reports Menu 

6. Return to Manpower 









RECORD TYPE MENU 


1. Officer 
3 |2. Enlisted 

zum | 3. Return to Personnel 
ü Data Menu 





MANPOWER REPORTS 
MENU 


1. Department 
2. Division 


3. Officer 

4. Status Reports Menu 
5. Manpower Menu 

6. Return to Reports 


STATUS REPORTS 
MENU 


. Department 

. Division 

. Designator/Rating 
. Grade/Paygrade 


. Officer 
. Manpower Reports 
Menu 


. Manpower Menu 
8. Return to Reports 


Figure H-1: Menu Tree 
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WELCOME TO 
AMA/PMS 


MAIN MENU 


1. Manpower 
2. Reports 
Se) Exitito OS 


Enter the number of your selection 


ere —_ —sIIa 


Figure H-2: Main Menu 
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AMA/PMS 


MANPOWER MENU 


1. Billet Data 
2. Personnel Data 


3. Return to Main Menu 


Enter the number of your selection 


— m 


Figure H-3: Manpower Menu 
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AMA/PMS 


REPORTS MENU 


1. Gains/Losses Report 
Manpower Report 
Status Report 

Ad Hoc Queries 


ER C MES 


Return to Main Menu 


Enter the number of your selection 


Figure H-4: Reports Menu 
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AMA/PMS 


BILLET DATA MENU 


1. Add New Billet 

Edit Billet Data 

Delete Billet 
Personnel Data Menu 


Heports Menu 


D 0c e 9 N 


Return to Manpower Menu 


Enter the number of your selection 


Figure H-5: Billet Data Menu 


132 


AMA/PMS 


PERSONNEL DATA MENU 


1. Add New Personnel 
Edit Personnel Data 
Delete Personnel 
Billet Data Menu 


Heports Menu 


ee O 


Return to Manpower Menu 


Enter the number of your selection 


Figure H-6: Personnel Data Menu 
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AMA/PMS 


MANPOWER REPORTS MENU 


1. Department 

Division 

Officer 

Status Reports Menu 


Manpower Menu 


EE SU L iS 


Return to Reports Menu 


Enter the number of your selection 


Figure H-7: Manpower Reports Menu 
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AMA/PMS 


STATUS REPORTS MENU 


le 


Se Se bo 


Department 

Division 

Designator / Rating 
Grade/Paygrade 

Officer 

Manpower Reports Menu 
Manpower Menu 


Return to Reports Menu 


Enter the number of your selection 


Figure H-8: Status Reports Menu 
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AMA/PMS 


BILLET TYPE MENU 


1. Officer 
2. Enlisted 
3. Return to Billet Data Menu 


Enter the number of your selection 


Figure H-9: Billet Type Menu 
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AMA/PMS 


BILLET DISPLAY MENU 


1. By Depariment 
By Division 
By BSC 


RZ IN 


Return to Billet Data Menu 


Enter the number of your selection 


Figure H-10: Billet Display Menu 
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AMA/PMS 


HECORD TYPE MENU 


1. Officer 
2. Enlisted 


3. Return to Personnel Data Menu 


Enter the number of your selection 


Figure H-11: Record Type Menu 
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APPENDIX I: MENU LOGIC (PSEUDO CODE) 


A. MAIN MENU 
Begin (*modulex) 
Case menu choice of: 
1: Get MANPOWER MENU 
2: Get REPORTS MENU 
End (*modulex) 
B. MANPOWER MENU 
Begin (*module*) 
Case menu choice of: 
1: Get BILLET DATA MENU 
2: Get PERSONNEL DATA MENU 
3: Get MAIN MENU 
End (*module*) 
C. REPORTS MENU 
Begin (*modulex) 
Case menu choice of: 
1: Get MANPOWER REPORTS MENU 
2: Get STATUS REPORTS MENU 
3: Get Gains/Losses Report (*procedure call*) 
4: Get MAIN MENU 


End (*module*) 
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D. BILLET DATA MENU 
Begin (*module*) 
Case menu choice of: 
1: Get BILLET TYPE MENU 
2: Get BILLET DISPLAY MENU 
3: Get BILLET DISPLAY MENU 
4: Get REPORTS MENU 
5: Get MANPOWER MENU 
End (*module*) 
E. PERSONNEL DATA MENU 
Begin (*module*) 
Case menu choice of: 
1: Get RECORD TYPE MENU 
2: Get Edit Personnel Data (*procedure call*) 
(*edit function handled by DBMS*) 
3: Get Delete Personnel Data (*procedure call*) 
(*delete function handled by DBMS*) 
4: Get REPORTS MENU 
5: Get MANPOWER MENU 
End (*module*) 
F. MANPOWER REPORTS MENU 
Begin (*module*) 
Case menu choice of: 
1: Get Department Manning Report (*procedure 
call*) 


2: Get Division Manning Report (*procedure call*) 
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3: Get Officer Manning Report (*procedure call*) 
4: Get MAIN MENU 
5: Get REPORTS MENU 
End (*module*) 
STATUS REPORTS MENU 
Begin (*module*) 
Case menu choice of: 


1: Get Department Status Report (*procedure 


call*) 
2: Get Division Status Report (*procedure call*) 
3: Get Designator/Rate Status Report (*procedure 
call*) 


4: Get Paygrade Status Report (*procedure call*) 
5: Get Officer Status Report (*procedure call*) 
6: Get MANPOWER MENU 
7: Get REPORTS MENU 
End (*module*) 
BILLET TYPE MENU 
Begin (*module*) 
Case menu choice of: 
1: Get Add Officer Billet (*procedure call*) 
(*add function handled by DBMS*) 
2: Get Add Enlisted Billet (*procedure call*) 
(*add function handled by DBMS*) 
3: Get BILLET DATA MENU 


End (*module*) 
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T. 


K. 


BILLET DISPLAY MENU 
Begin (*module*) (*display function handled by DBMS*) 
Case menu choice of: 
1: Get Display Department Billets (*procedure 
call*) 
2: Get Display Division Billets (*procedure 
call*) 
3: Get Display Billet By BSC (*procedure call*) 
4: Get BILLET DISPLAY MENU 
End (*module*) 
RECORD TYPE MENU 
Begin (*module*) 
Case menu choice of: 
1: Get New Officer Record (*procedure call*) 
2: Get New Enlisted Record (*procedure call*) 
3: Get PERSONNEL DATA MENU 
End (*module*) 
REPORT GENERATION PROCEDURES 
1. Department/Division Manning Report 
a. Display data by Department then by Division. 
b. Records/Fields used: 
1) EBILLET/BSC, Billet Title, BA, Rate, PNEC, 
SNEC, DName, DivName 
2) ENLISTED/BSC, Name, Rate, PNEC, SNEC, PRD, 
EAOS 


C. Sort EBILLET records by DName, DivName. 
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d. For each BSC in EBILLET, compare and match 
ENLISTED records to EBILLET records by keying on 
BSC. 
e. Print data per report format in Appendix D. 
Department/Division Status Report 
a. Display data by Department then by Division. 
b. Records/Fields used: 
1) EBILLET/BSC, Billet Title, BA Rate, PNEC, 
SNEC, DName, DivName 
2) ENLISTED/BSC, PRD, EAOS 


C. Sort EBILLET records by DName, DivName. 





d. For each BSC in EBILLET, compare and match 
ENLISTED records to EBILLET records by keying on 
BSC: 
f. Using ENLISTED records calculate number of 
personnel on board for each BSC for the current 
month and for each of the next four (4) months. 
(For each BSC in ENLISTED record, if EAOS < PRD, use 
EAOS to determine projected on board; else use PRD.) 
g. Print data per report format in Appendix D. 
Officer Manning Report 
a. Display data by Department then by Division. 
b. Records/Fields used: 
1) OBILLET/BSC, Billet Title, BA, Grade, 
Designator, DName, DivName 


2) OFFICER/BSC, Name, Grade, Designator, PRD 
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c. Sort OBILLET records by DName, DivName. 





d. For each BSC in OBILLET, compare and match 
OFFICER records to OBILLET records by keying on BSC. 
e. Print data per report format in Appendix D. 
Officer Status Report 
a. Display data by Department then by Division. 
b. Records/Fields used: 

1) OBILLET/BSC, Billet Title, Grade, Designator, 

BA, DName, DivName 

2) OFFICER/BSC, PRD 
C. Sort records on BSC. 
d. For each BSC in OBILLET, determine the number of 
OFFICERS assigned against it for current month and 
each of the next four (4) months. 
e. Print data per report format in Appendix D. 
Grade/Paygrade Status Report 
a. Records/Fields used: 

1) OBILLET/Grade, BA 

2) OFFICER/Grade, PRD 

3) EBILLET/Paygrade, BA 

4) ENLISTED/Paygrade, PRD, EAOS 
b. Sort OBILLET and OFFICER records on Grade. 
C. Sort EBILLET and ENLISTED records on Paygrade. 
d. Calculate - OFFICER PAYGRADE STATUS REPORT 

1) Using OBILLET records, count number of BA for 


each Grade. 
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2) Using OFFICER records, count number of each 
Grade currently assigned. 
3) Calculate percent of BA currently filled for 
each Grade (COB/BA). 
4) Using the PRD field of OFFICER record, 
calculate the number of each Grade on board for 
the current month and for each of the next seven 
(7) months. 

e. Calculate - ENLISTED PAYGRADE STATUS REPORT 
1) Using EBILLET records, count number of BA for 
each Paygrade. 
2) Using ENLISTED records, count number of each 
Paygrade currently assigned. 
3) Calculate percent of BA currently filled for 
each Paygrade (COB/BA). 


4) Using the PRD or EAOS field of ENLISTED 





record, calculate the number of each Paygrade on 
board for the current month and for each of the 
next seven (7) months. (For each ENLISTED 
record, if EAOS « PRD, use EAOS to determine 
projected on board; else use PRD. 

f. Print data per report format in Appendix D. 

Designator/Rating Status Report 

a. Display data by Designator and Rating 

b. Records/Fields used: 


1) OBILLET/Grade, BA, Designator 
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C. 


a. 


2) OFFICER/Grade, Designator 

3) EBILLET/BA, PNEC, SNEC, Rating, Paygrade 

4) ENLISTED/PNEC, Rate 

Sort OBILLET and OFFICER records on Designator. 


Sort EBILLET and ENLISTED records on Rate, then 


by PNEC (if one is assigned). 


e. 


g. 


Calculate - DESIGNATOR STATUS REPORT 
1) Using OBILLET records: For each Desiqnator in 
OBILLET, count number of BA in each Grade. 
2) Using OFFICER records: For each Designator in 
OFFICER, count number of personnel on board in 
each Grade. 
Calculate - RATING STATUS REPORT 
1) Using EBILLET records: 
a) For each Rating in EBILLET, count number 
of BA for each Paygrade. 
b) Subdivide each Rating by PNEC if one is 
assigned. 
2) Using ENLISTED records: 
a) For each Rate in ENLISTED, count number 
of personnel currently on board. 
b) Subdivide each Rate by PNEC if one is 
assigned. 


Print data per report format in Appendix D. 
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Gains/Losses Report 


a. 


a) 


Records/Flelds used: 

1) OFFICER/Name, Grade, Designator, PRD 

2) ENLISTED/Name, Rate, PNEC, PRD, EAOS 

Sort records by PRD. 

Calculate - GAINS REPORT 

1) Using OFFICER and ENLISTED records, identify 
those personnel who will be arriving at the 
activity within the next six (6) months. (This 
date will be reflected in the PRD field with an 
"A" as the first digit.) 

Calculate - LOSSES REPORT 

1) Using OFFICER and ENLISTED records, identify 
those personnel who will be departing the 
activity within the next six (6) months. (For 
each ENLISTED record, if EAOS « PRD, use EAOS to 
determine projected on board; else use PRD.) 


Print data per report format in Appendix D. 
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